将应用程序层拆分为不同的程序集

Question

我的公司正在进行辩论.有些人主张将业务,数据和业务实体转移到一个组件中

• 可发现性目的.让您轻松找到所需内容.
• 减少我们需要添加到项目以进行开发的dll数量

其他引用应用程序架构指南的人希望每个层和业务实体都在一个单独的程序集中.

请注意

• 我们的业务和数据层都包含com +组件.
• 我们当前的硬件架构在同一个盒子上有Web,业务和数据.
• SQL在另一个盒子上.
• 我们目前没有使用dll版本控制,因为它对com +无论如何都是无用的.

一些使用有一种直觉,我们应该分割我们的业务,数据和实体,但缺乏理由.

• 可能会减少内存消耗
• 仅通过将业务层程序集添加到Web项目来鼓励正确的体系结构.如果数据服务也可用,则可以轻松地以错误的方式执行操作
• 当我们从业务和数据层拆分我们的Web服务器时,我们不需要安装垃圾,我们不需要从神组件.

现在我们的系统中有大约600个dll.所以我们处于一个极端,一切都被分裂了.有一些肯定会发生合并,但正在提出的是将我们带到一个完全的另一个极端,每个应用程序都在一个dll中.

我可以从这个常见问题得到一些外部观点吗？

谢谢!

Answer 1

DLL 或程序集是分发单元。

1. 如果特定名称空间或类中的代码与另一个名称空间或类紧密耦合，那么它应该位于相同的分发单元中。如果 foo.* 文件中的代码在不需要 bar.* 文件中的代码的情况下永远不会被使用，那么您也可以将它们构建到相同的分发单元中。
2. 如果命名空间或类组代表可重用组件（即代码正在两个或多个产品/应用程序中使用），那么它是单独版本化并成为其自己的分发单元的良好候选者。

对我来说，这主要是关于内聚、耦合和重用。
我喜欢特定分布单元中的类具有内聚性，但我不喜欢分布单元之间的耦合（我几乎总是喜欢依赖包含接口的第三个分布单元，以便通过对抽象的依赖来实现耦合而不是结核）。在做出有关分配单位的决策时，重用对我来说是关键。如果代码要在多个应用程序/产品中使用，那么它需要是一个单独的分发单元，具有独立于应用程序版本号的自己的版本号。