Orchard，基于插件的架构，设计模式

Question

我正在做软件架构、分层的研究，看了很多开源的.net项目，比如Orchard CMS。

我认为Orchard是一些设计模式的一个很好的例子。

据我所知，由于误用，UI、服务、存储库和实体应该位于不同的程序集中。但在Orchard中(由于模块化和可插拔)，我在相同的文件夹和相同的命名空间中看到了服务、存储库和实体类以及接口。

它不是反模式吗，或者它对模式是正确的吗？

Answer 1

TL;DR:组件不一定是正确的分离设备。

不，重要的是它们是分开的，而不是在不同的程序集中。此外，您在大多数应用程序中分解事物的方式必须与在可扩展CMS中所做的不同。可扩展CMS中的正确分离是分离成可以随意添加和删除的解耦功能，而常规分层应用程序需要解耦各层，以便能够以最小的风险和影响对其进行处理和重构。正确的比较实际上是将其中一个应用程序与Orchard中的模块或功能进行比较，而不是与Orchard作为一个整体进行比较。但当然，好的实践应该在模块中使用，而且它们通常是这样的。

现在分离成程序集是一个单独的问题，它更多的是技术上的而不是架构上的。您可以将程序集视为独立代码的容器，创建程序集的目的是为了代码重用和动态链接，但不能特别将其看作是一种分隔层的方式。这就是为什么它们在Orchard中与代码重用的单元模块重合的原因。

还要考虑到这一点的实际方面:良好的架构实践有一个主要目标，那就是使应用程序更容易维护，成本更低(这一点并不令人惊讶(没有！)通过使顾问能够建立只有他们能理解的宇航员架构来使他们变得富有)。第二个目标是对可伸缩和性能良好的应用程序进行编码(尽管这是一个更棘手的目标，因为它很容易导致过早优化，这是大多数软件邪恶的根源)。

对于第一个目标，概念分离是最重要的，但这种分离的方式通常不是很重要。

不幸的是，第二个目标与使用程序集作为分离设备的想法相冲突: Orchard，因为在您开始添加可选模块之前，它已经有几十个程序集了。而且程序集也不是免费的。它们需要动态编译、加载、with、内存开销等。换句话说，为了获得良好的性能，你通常会想要减少程序集的数量。

如果您希望像现在一样将Orchard站点划分为模块的程序集，然后将这些模块中的每个模块划分为分层的程序集，则必须将模块的数量乘以层数。这将需要加载数百个程序集。不太好。事实上，我们甚至正在考虑一种动态编译的选项，以将所有模块构建到单个程序集中。