我更喜欢将我的 3 层 .NET 应用程序分离到单独的项目中，以增强模块化和关注点分离，但是我的计算机上存在性能问题（内存和处理能力不足），因此 Visual Studio 运行缓慢且不愉快当一个解决方案中有很多项目时，我虽然将所有层放在一个程序集中，但仍然使用代码并设计它，就好像每种类型都在其各自的层中一样。我想知道一件事，如果你们中有人尝试过这样做，您有什么建议或不建议或对此有任何想法吗？
我不是在寻找讨论，我只是想知道这样做是否有任何严重的风险？
【问题讨论】：
标签： .net design-patterns architecture
分层在 .NET 和其他强类型平台中有益的原因之一是您不能（轻松）在项目/库之间添加循环引用。这确保了，至少在包级别，依赖项将形成一个有向无环图（DAG）。这是一件好事，因为它迫使我们减少耦合。
在 C# 中，完全可以编译形成循环图的代码（ClassA 引用 ClassB，它引用 ClassC，而后者又引用 ClassA）。因此，将所有代码放入单个 Visual Studio C# 项目中会消除分层提供的一些编译时保护。
但是，如果您改为使用 F# 编写整个项目，您将重新获得编译时保护，因为如果 F# 代码包含循环，则无法编译（尽管可以声明特定的异常该规则在一个模块中...参见Mutually Recursive Types部分）。
所以，如果用 C# 编写整个应用程序，你很可能会遇到问题，但如果你用 F# 编写它，你应该会很好。
【讨论】：
主要风险是随着时间的推移，您的代码层会随着代码的更改而被侵蚀。发生这种情况是因为您或您的团队在进行代码更改时没有意识到他们正在破坏分层（当您有单独的项目时相对明显）。
如果只有您并且您清楚地记住了整个代码库，这可能不是问题。否则，您可以使用命名空间来更容易地了解任何类被认为属于哪个层。
当然，语言中没有任何东西可以防止命名空间之间的不良依赖关系蔓延。为了确保这一点，您需要语言之外的东西来定义和实施分层。这通常意味着使用单独的工具来定义架构组件和依赖规则，将它们映射到代码，并检测何时违反规则。 Studio Ultimate 有一个layer diagram 可以执行此操作，其他工具也可以执行此操作，例如Lattix（依赖矩阵）和Structure101（architecture diagrams）。
【讨论】：
只要你保持纪律以保持层正确分离，你应该没问题。
【讨论】：
如何通过单元测试来执行架构？您将需要一个用于整理依赖关系的 API，以及一种用于表达编写测试的边界的语言。
我看到例如 NDepend 有一个 API，它可能可用于确定依赖关系。然后，您可以使用 NDepend API 和反射编写将命名空间作为边界的测试。
如果有人这样做会很酷。
【讨论】：
根据我的经验，当源文件数量相似时，大型项目的表现与多项目解决方案一样糟糕。主要这似乎与磁盘性能（我认为我拥有的机器是 5400 rpm 磁盘）和阻止读取和写入大量文件（磁盘 I/O 活动）有关。 Visual Studio 所做的很多事情都是处理磁盘（编译、调试、智能感知的文件解析等），这似乎是我的问题的来源。
我很想尝试将文件保存在单独的项目中，并为每个项目创建一个解决方案文件。
【讨论】：