我正在研究软件架构、分层，并查看了许多开源 .net 项目，例如 Orchard CMS。
我认为 Orchard 是一些设计模式的一个很好的例子。
据我所知，由于滥用，UI、服务、存储库和实体应该在单独的程序集中。但是在 Orchard 中，（由于是模块化和可插拔的）我在同一个文件夹和同一个命名空间中看到服务、存储库和实体类和接口。
它不是反模式，还是对模式正确？
问问题
1735 次
1 回答
12
TL；DR：组件不一定是正确的分离装置。
不，重要的是它们是分开的，而不是它们在单独的程序集中。此外，在大多数应用程序中考虑因素的方式必须与在可扩展 CMS 中的方式不同。可扩展 CMS 中的正确分离是可以随意添加和删除的解耦功能，而常规分层应用程序需要解耦层，以便可以以最小的风险和影响进行处理和重构。正确的比较实际上是在其中一个应用程序和 Orchard 中的模块或功能之间进行比较，而不是在整个 Orchard 之间进行比较。但是，当然，应该在模块中使用良好的实践，而且通常是这样。
现在分离成组件是一个单独的问题，它比架构更具技术性。您可以将程序集视为自包含代码的容器，其创建目的是为了代码重用和动态链接，但不是特别作为分离层的一种方式。这就是为什么它们在 Orchard 中与代码重用单元模块一致。
还要考虑这一点的实际方面：良好的架构实践有一个主要目标，那就是使应用程序更容易维护并且更便宜（而不是，令人惊讶的是（不是！）通过使顾问能够设置宇航员架构来使他们变得富有他们可以理解）。第二个目标是编写可扩展和性能良好的应用程序的代码（尽管这是一个更棘手的目标，因为它很容易导致过早优化，这是大多数软件邪恶的根源）。
对于第一个目标，概念分离是最重要的，但这种分离的方式通常不是很重要。
不幸的是，次要目标与使用组件作为分离设备的想法相冲突：在您开始添加可选模块之前，Orchard 已经拥有数十个组件。集会不是免费的。它们需要动态编译、加载、jitted、内存开销等。换句话说，为了获得良好的性能，您通常希望减少程序集的数量。
如果您想像现在一样将 Orchard 站点拆分为模块组件，然后将这些模块中的每一个拆分为分层组件，则必须将模块数乘以层数。那将是要加载的数百个程序集。不好。事实上，我们甚至在考虑动态编译的选项，将所有模块构建到单个程序集中。
于 2012-05-27T19:42:12.987 回答