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

Question

我正在研究软件架构、分层，看了很多开源的 .net 项目，比如 Orchard CMS。
我认为Orchard 是一些设计模式的好例子。
据我所知，UI、服务、仓储和实体应该在不同的程序集中进行分离，以避免错误使用。但是在Orchard 中，由于具有可扩展性和可插拔性，我看到了同一文件夹和命名空间中的服务、仓储和实体类和接口。
这是反模式还是正确的模式呢，请您帮我解答？

- alper

Answer 1

TL;DR: 程序集不一定是正确的分离设备。

重要的是它们被分离开来，而不是它们在单独的程序集中。此外，在大多数应用程序中，您需要进行不同于可扩展CMS的因素分解。在可扩展的CMS中，正确的分离方式是将其分成可以随意添加和删除的解耦合“功能” ，而常规分层应用程序则需要将层解耦合，以便可以在最小风险和影响下进行工作和重构。正确的比较实际上是在这些应用程序之一与Orchard中的模块或特性之间进行的，而不是与整个Orchard相比。但当然，在模块内应使用良好的做法，而且通常会这样做。

现在，程序集的分离是一个单独的问题，比架构更加技术化。您可以将程序集视为自包含代码的容器，旨在用于代码重用和动态链接，但并不特别适用于分离层次。这就是为什么在Orchard中，它们与代码重用单元模块重合的原因。

此外，请考虑这个实际问题：良好的架构实践有一个主要目标，那就是使应用程序更易于维护和更经济实惠，而不是（令人惊讶的）使顾问通过启用只有他们能够理解的宇航员架构而变得富有。第二个目标是将可扩展且功能良好的应用程序所需的内容进行编码（尽管这是一个棘手的目标，因为它很容易导致过早优化，这是大多数软件问题的根源）。

对于第一个目标，概念上的分离最重要，但通常其方式并不重要。

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

如果您想将Orchard站点分离为模块的程序集，然后将每个模块分离为分层的程序集，那么您必须将模块数量乘以层数。这将需要加载数百个程序集，不太好。事实上，我们甚至考虑了一个选项来进行动态编译，将所有模块构建成单个程序集。

- Bertrand Le Roy

---

我也大多数情况下和你解释的一样，只是想听听专家对软件架构这个问题的看法，在做研究的时候......谢谢你的回答，被最权威的人回答是很有意义的 :) - alper

@bertrand 不要再考虑了，只需添加该选项以将所有模块构建为单个程序集。 - rfcdejong

如果你能证明确实存在问题，并且这将是一个有效的解决方案，我们就会去做。 - Bertrand Le Roy