将多个程序集公开为单个 API
在我开始构建解决方案之前，我并没有真正考虑过这个方面...
为了简化，我的应用程序公开了一个 API 供其他应用程序使用。该 API 在概念上由两部分组成：“操作”类和数据类型对象。其中每一个都在自己的项目中。
（我现在不是在问类设计，这是一个完全独立的问题 - 这是有充分理由的。）
现在，这些位于单独程序集中的主要原因之一是，它们在内部使用彼此非常分开：数据类型在内部广泛使用 - 然而，操作类只是应用程序的公共面孔，根本不在内部使用。
到目前为止，一切都很好，一切都有意义......
然后我开始插入 API，并意识到 - 调用应用程序需要引用两个程序集，而不仅仅是一个程序集，才能使用 API。
那么这里最好的举动是什么？
- 根据内部逻辑的要求，留下两个独立的程序集，并迫使我们的客户执行额外的、不需要的和不漂亮的额外步骤。
- 混合两个程序集的使用，并仅构建一个程序集。这意味着内部类将需要对外部 API 的引用...这可能导致循环引用...
- 其他一些出色的解决方案（这确实是我所希望的答案？ ）
Reeeheely 希望在 3 领域有新的东西......
Didn't really consider this aspect till I started building my solution...
To simplify, my application exposes an API to be used by other applications. The API is conceptually comprised of two parts: "Action" classes, and data type objects. Each of these is in its own project.
(I'm not asking now about class design, that's a whole separate issue - there are good reasons for this.)
Now, one of the main reasons these are in separate assemblies, is that internally they are used very separate from each other: the data types ARE used internally, extensively - however, the action classes are simply the public face of the application, and NOT used internally at all.
So far, all was good, it all made sense...
Then I started plugging in the API, and realized - calling apps would need to reference TWO assemblies, instead of just the one, in order to use the API.
So what would be the best move here?
- Leaving two separate assemblies, as their internal logic demands - and forcing our clients to perform an extra, unrequired and unpretty extra step.
- Commingling between usages of the two assemblies, and building only a single assembly. This would mean the internal classes will need a reference to the external API... and this might lead to circular references...
- Some other brilliant solution (which is really the answer I'm hoping for?)
Reeeheely hoping for something new in the area of 3...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您不能构建包含要使用的 API 的第三个程序集吗？这将引用 2 个工作程序集并为第 3 方提供单一入口点？
更新：
根据评论中的对话和思考，我完全同意 Avid 正在尝试做的事情，它确实使使用单个 dll 的事情变得更清晰，但只要它有记录并且可以工作这并不重要。一旦被引用，它就会被引用。开发人员很快就会解决这个问题。我当然不会尝试添加额外的构建步骤来合并事物来解决这个问题。 （这只是我的观点）
为了回答这个问题，我会选择原帖中的选项 1。
Can you not build a 3rd Assembly that contains the API to be consumed? This will reference the 2 working assemblies and provide a single entry point for 3rd parties?
UPDATE:
Based on the conversation in the comments and thinking this through, I absolutely agree with what Avid is trying to do, it does make things cleaner having a single dll, but as long as its documented and works it doesnt really matter that much. Once its referenced it's referenced. Developers will soon figure this out. I would certainly not try and add additional build steps to merge things to get around this. (This is just my opinion)
To answer the question I would go with option No. 1 in the original post.
也许合并它们？ ： http://research.microsoft.com/en-us/people /mbarnett/ILMerge.aspx
Maybe merge them? : http://research.microsoft.com/en-us/people/mbarnett/ILMerge.aspx