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