何时将代码分离到新程序集（DLL）中
我作为团队的一员创建了一个企业应用程序，该应用程序将在新的 C# .NET Windows 应用程序及其 Web 应用程序中使用。另一位开发人员比我更喜欢将事物分离到单独的项目中。他的回答总是“关注点分离”，我不确定我是否同意这一点。
我的理论是，当代码能够被其他使用者共享时，您可以创建单独的程序集。关注点分离应该由命名空间来处理。分发一个包含大量来自版本控制、混淆等的程序集的应用程序可能是一项额外的工作/挑战/噩梦。所以这让我很担心，我试图找出当代码被破坏时的经验法则是什么进入它自己的程序集。
您将代码分离到其他程序集中与在应用程序中使用命名空间和其他组织技术的经验法则是什么？是否有关于此的任何指导或模式/实践，我可以阅读以说“是的，他是对的”或“请阅读此内容”。
谢谢。
I work as part of a team creating an enterprise application that will be used in a new C# .NET Windows Application and a Web Application of the same. One of the other developers likes to separate things out into separate projects a bit more than I. His answer is always "separate of concerns" which I'm not sure I agree with.
My theory is you create separate assemblies when that code is capable of being shared by other consumers. Separation of concerns should be handled by namespaces. It can be an additional effort/challenge/nightmare to distribute an application with a large number of assemblies from versioning, obfuscation, etc. So it concerns me and I'm trying to find out what the rule of thumb is for when code is broken out into its own assembly.
What is your rule of thumb for separating code into other assemblies vs. using namespaces and other organization techniques within an application? Is there any guidance on this or patterns/practices that I can read to either say "yeah, he's right" or "please read this".
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为你有一个沟通问题，或者一个术语问题，因为关注点分离通常意味着不同的东西。
严格来说，关注点分离处理诸如单一责任原则之类的事情，其中每个类都处理它自己的领域。单一责任原则规定，一个类应该只有一个改变的理由。
关注点分离的一些示例是视图和模型抽象模式，例如 MVC 或 MVVM。每个组件，无论是视图还是模型，都处理用户界面抽象或数据和验证，但不能同时处理两者。
当代码可以在多个项目之间共享时（就像您自己已经指出的那样），将代码拆分为单独的程序集是一种很好的做法。可以通过使用不同的命名空间来简单地构建代码。
当您有大量代码时，程序集是对代码进行分组的自然方式，并且当您在不同级别上管理代码并且具有非常受控的可扩展性点并希望将其锁定时，程序集提供了该级别的隔离。
I think you have a communication issue, or an issue with nomenclature because, separation of concerns, generally means something different.
Strictly speaking, separation of concerns, deals with things like the single responsibility principle, in that, each class kinda deals with it's own domain. The single responsibility principle states that a class, should only have one reason to change.
Some examples of separation of concerns are view and model abstraction patterns such as MVC or MVVM. Where each component, be it the view or model, deals with user interface abstraction or data and validation, but not both.
Splitting up code into separate assemblies is a good practice when the code can be shared between multiple projects (like you yourself already pointed out). Simply structuring code can be done by using different namespaces.
When you have a lot of code, assemblies are a natural way of grouping code and when you managed code on different levels and have very controlled points of extensibility and want to lock that down, assemblies provide that level of isolation.
部分原因是 Shark 已经提供的推理（版本控制以及重新编译/替换较大应用程序所使用的选定程序集）。但我也倾向于创建程序集，这样做形成一个独立有用且完整的代码单元。
例如，我可能会创建一个解析单元来解析 HTML（这是一个傻瓜的差事，我知道……这是一个示例！）以便在更大的应用程序中使用。如果 HTMLParsingUnit 的功能相对完整（换句话说，不是特定于较大的应用程序），那么我可能会在自己的程序集中创建它，以便由其他代码重用，并封装版本控制/更改。
同样，我曾经必须创建映射并提供从 ASNI SQL 到 .NET CLR 类型的数据类型类。我为此创建了一个独立的 DLL，因为我认为它可能会在其他项目中派上用场。显然，这样做意味着完全抽象组件的组件，但这使维护变得更加容易。最终，我确实在几个不同的项目中重复使用了这个程序集。
只是我的两分钱。 。 。
In part due to the reasoning already provided by Shark (versioning, and recompile/replacement of select assemblies consumed by a larger application). But also I tend to create assemblies when doing so forms an independently useful and complete code unit.
For example, I might be creating a parsing unit to parse HTML (a fool's errand, I know . . . this is an example!) for use within a larger application. If the functionality of HTMLParsingUnit is relatively complete (in other words, not specific to the larger application) then I would likely create this in its own assembly both for re-use by other code, and to encapsulate versioning/changes.
Similarly, I once had to create a mapping and provide classes of DataTypes from ASNI SQL to .NET CLR types. I created an independent DLL for this, as I figured it might come in handy in other projects. Obviously, doing so meant abstracting the components of the assembly comepltely, but this made maintenence easier. Ultimately, I DID re-use this assembly in several different projects.
Just my two cents . . .
我的经验法则是，如果该 DLL 可以被其他应用程序使用，则始终首先将不同代码库中的代码分开。
但对我来说另一个考虑因素是版本控制。如果经常对一组代码进行改进/扩展，对我来说，将其作为单独的 DLL 会更容易，因此项目中的其他 DLL/exe 绝对不知道这些更改，除非调用也发生了更改。
我认为这是将代码分离到不同 DLL 中的两个主要原因。
My rule of thumb is to always separate code in different code libraries first and foremost if that DLL can be consumed by other applications.
But another consideration for me is with versioning. If a grouping of code will often times be improved upon/scaled, to me it is easier to have that as a separate DLL, so the other DLLs/exe in the project are absolutely ignorant to the changes, unless the calls are also altered.
I think those are the two main reasons for separating code into different DLLs.