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

Question

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

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

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

请注意

• 我们的业务和数据层都包含com +组件。
• 我们当前的硬件架构在同一个盒子上有网络，业务和数据。
• 另一个框上的SQL。
• 我们目前没有使用dll版本控制，因为它对com +反正无用。

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

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

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

我可否就这个常见问题获得一些外界观点？

谢谢！

Answer 1

DLL或程序集是分发的单位。

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

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

Answer 2

分割物理部署边界是个好主意。如果您有可以托管以供远程使用的组件，那么单独的程序集是有意义的。对于初学者来说，这可能是你能分开的最简单，最实用的线。例如，当您希望 Web层包含业务服务和数据访问代码时，很少会出现这种情况。

从那里，尝试将程序集减少到对版本有意义的东西。如果你总是需要将10个组件一起复制，那么它们可能应该构建为一个。

Answer 3

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

我们不会竭尽全力将代码推送到它不属于的程序集中。但是我们绝对不会在没有充分理由的情况下创建新程序集。通常，我们有应用程序的共享逻辑（业务对象等）的程序集和用户界面的程序集（Web程序集，WinForms程序集等）。我们也不会在程序集中复制代码/类，以避免创建新的程序集。