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