我作为团队的一员工作，创建一个企业应用程序，该应用程序将用于新的 C# .NET Windows 应用程序和相同的 Web 应用程序。其他开发人员之一比我更喜欢将事物分成单独的项目。他的回答总是“关注点分开”，我不确定我是否同意。
我的理论是，当代码能够被其他消费者共享时，您可以创建单独的程序集。关注点的分离应该由命名空间处理。分发具有大量来自版本控制、混淆等程序集的应用程序可能是一项额外的努力/挑战/噩梦。所以这让我很担心，我试图找出当代码被破坏时的经验法则是什么输出到它自己的程序集中。
您将代码分离到其他程序集与在应用程序中使用命名空间和其他组织技术的经验法则是什么？有没有关于这个或模式/实践的指导，我可以读到“是的，他是对的”或“请阅读这个”。
谢谢。
【问题讨论】：
标签： .net design-patterns c#-4.0 architecture anti-patterns
我认为您有沟通问题或命名问题，因为关注点分离通常意味着不同的东西。
严格来说，关注点分离涉及单一职责原则之类的事情，每个类都处理自己的领域。单一责任原则指出，一个类，应该只有一个改变的理由。
关注点分离的一些示例是视图和模型抽象模式，例如 MVC 或 MVVM。每个组件，无论是视图还是模型，都处理用户界面抽象或数据和验证，但不能同时处理两者。
当代码可以在多个项目之间共享时（就像您自己已经指出的那样），将代码拆分为单独的程序集是一种很好的做法。可以通过使用不同的命名空间来简单地构建代码。
当您拥有大量代码时，程序集是对代码进行分组的一种自然方式，并且当您在不同级别上管理代码并且具有非常受控的可扩展点并希望将其锁定时，程序集提供该级别的隔离。
【讨论】：
部分原因是 Shark 已经提供了推理（版本控制，以及重新编译/替换大型应用程序使用的选定程序集）。但我也倾向于在创建程序集时创建一个独立有用且完整的代码单元。
例如，我可能正在创建一个解析单元来解析 HTML（我知道这是一个傻瓜的差事……这是一个示例！），以便在更大的应用程序中使用。如果 HTMLParsingUnit 的功能相对完整（换句话说，不是特定于更大的应用程序），那么我可能会在它自己的程序集中创建它以供其他代码重用，并封装版本控制/更改。
同样，我曾经必须创建一个映射并提供从 ASNI SQL 到 .NET CLR 类型的 DataTypes 类。我为此创建了一个独立的 DLL，因为我认为它可能会在其他项目中派上用场。显然，这样做意味着将程序集的组件完全抽象化，但这使得维护更容易。最终，我确实在几个不同的项目中重新使用了这个程序集。
只有我的两分钱。 . .
【讨论】：
我的经验法则是，如果该 DLL 可以被其他应用程序使用，则始终首先将不同代码库中的代码分开。
但对我来说，另一个考虑因素是版本控制。如果一组代码经常会被改进/缩放，对我来说，将它作为一个单独的 DLL 更容易，所以项目中的其他 DLLs/exe 对更改完全不了解，除非调用也被更改。
我认为这是将代码分成不同 DLL 的两个主要原因。
【讨论】：