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

Question

我公司正在进行一场辩论。有些人主张在一个程序集中移动业务、数据和业务实体。

• Discoverability的目的。
• 减少了我们需要添加到开发

项目中的dll的数量

其他人引用应用程序体系结构指南，希望将每个层和业务实体放在一个单独的程序集中。

请注意

我们的业务层和数据层都由com + components.

• Our组成，当前的硬件体系结构在相同的框上有web、业务和数据。

• 我们目前没有使用dll版本控制，因为它对com+几乎毫无用处。

有些人有一种直觉，认为我们应该分裂我们的业务、数据和实体，但缺乏理由。

通过只将业务层程序集添加到web项目中，

• 可能会减少内存
• 的适当架构。如果数据服务也是可用的，那么当我们将web服务器从业务层和数据层分离开来时，可以很容易地以错误的方式完成
• 的工作，而不必安装我们不需要的来自上帝程序集的垃圾。

现在我们的系统中有大约600个dll。所以我们处在一个极端，所有的东西都被分割开了。有一些肯定的整合是可以发生的，但所提议的是把我们带到一个完整的另一个极端，每个应用程序都在一个dll中。

我能在这个共同的问题上得到一些外界的看法吗？

谢谢!

Answer 1

DLLs或程序集是分布的单位。

1. 如果特定名称空间或类中的代码与另一个名称空间或类紧密耦合，那么它应该处于相同的分发单元中。如果foo.*文件中的代码不需要在条形图中使用。*文件，那么您最好将它们构建到distribution.
2. If的同一个单元中--名称空间或类组代表可重用的组件(也就是说，该代码用于两个或多个产品/应用程序)，那么单独进行版本化并成为自己的分发单元是一个不错的选择。

对我来说，这主要是关于内聚力、耦合和重用。

我喜欢特定分发单元中的类具有凝聚力，我不喜欢分布单元之间的耦合(我几乎总是希望在包含接口的第三个分发单元上存在依赖关系，以便通过依赖抽象而不是具体化来实现耦合)。在决定分发单元时，重用是我的关键。如果代码要在多个应用程序/产品中使用，那么它需要是一个单独的分发单元，它的版本号与应用程序版本号是分开的。

Answer 2

在物理部署边界上拆分是一个好主意。如果您有可以托管以供远程使用的组件，那么单独的程序集就有意义了。对于初学者来说，这可能是最简单也是最坚实的一条线。例如，您希望web层同时包含业务服务和数据访问代码的情况很少。

从这里开始，尝试将程序集简化为独立版本的有意义的东西。如果您总是必须将10个以上的程序集复制到一起，那么它们可能应该作为一个程序集构建。

Answer 3

我们团队的目标是尽可能少的集合。除了列出的好处之外，我还发现，当DLL数量较少时，处理DLL版本化噩梦就更容易了。使用过多的程序集还会带来在程序集之间创建循环引用的风险。

我们不会想尽办法将代码插入不属于它的程序集中。但是我们绝对不会在没有充分理由的情况下创建一个新的程序集。通常，我们有一个用于应用程序共享逻辑的程序集(业务对象等)和一个用于用户界面的程序集( WinForms程序集、WinForms程序集等)。我们也不重复程序集之间的代码/类，只是为了避免创建新程序集。