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