【译】Orchard架构设计模式

【http://stackoverflow.com/questions/10774185/orchard-plug-in-based-architecture-design-patterns】

【问】：
　　我目前正在研究软件架构、分层，并为此看了许多开源的.net项目，其中包括Orchard CMS。 我认为Orchard是一个很好的设计范例。
　　据我所知，良好的架构应该是UI,Service,Repositories和Entities应该被分离在不同的程序集中。但是在Orchard里面，我看见service，repository，entity相关的类和接口都在相同的文件夹和命名控件下。
　　请问这是一个反模式么？或者说这样设计架构对么?

 

【答】：
　　首先，程序集并不是分离架构的必要条件。

　　对于你的问题，回答是否定的。判断是否正确真正重要的是他们确实已经被分离了，而不是他们是否应该在不同的程序集中。而且，与大部分系统不一样，开发一个可扩展的CMS的所要考虑的因素是不同的。在一个可扩展的CMS系统中，正确的分离方式应该是解耦那些将来随时可能添加或者移除的features。然而在一个平常的分层系统中，则要求通过分层解耦来降低他们互相影响的风险。真正应该拿来比较的应该是分层系统和Orchard中的一个模块，而不是将他与整个Orchard进行比较。当然了，正如Orchard所实现的那样，好的实践都在模块里面使用了。

　　按程序集划分是基于分离考虑，这本身已经偏向于技术性的东西而不是架构了。你可以把程序集看成一个包含了代码的容器，这个容器是为了代码复用和动态链接。但不是实现分层的方法。这也是为什么他们使用模块来进行代码复用的原因。

　　另外我们从现实层面考虑：好的架构有一个主要的目的，就是使得程序可以更方面和廉价的进行维护（同时并不是像设计宇航系统那样设计出只有他们自己看得懂的架构）。其次一个目的是编写出可扩展和性能良好的应用程序（尽管这个目的更加难以实现，因为他很容易导致过早优化，这是许多软件的灾难源泉）。

　　对于第一个目的，概念分离是很重要的，但是具体通过什么方式进行分离却不是那么重要。
而第二个目的则恰好与使用程序集进行分层的理念相违背：在你添加额外的模块之前，Orchard已经有了许多的程序集。这些程序集从来都不是无限制使用的。在Orchard中，他们需要被动态的编译，加载，JIT翻译，并通过内存来运行等等。从性能方面来看，你通常应该降低程序集的数量来达到性能优化的目的。

　　对于现今的Orchard来说，如果你要将Orchard划分到不同的程序集中，然后将每个模块依次划分到这些程序集。那么你将需要分层数*模块数的程序集，成百个的程序集到时候会需要被加载，显然不好。事实上，我们甚至考虑过将所有的程序集动态的编译到一个程序集中。