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

Question

我的公司正在进行一场辩论。一些人提倡将业务、数据和业务实体移动到一个组件中，以实现

可发现性目的。让您轻松找到所需内容。

减少我们需要添加到开发项目中的dll的数量

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

请注意

我们的业务层和数据层都由 com + 组件组成。

我们当前的硬件架构在同一个盒子上拥有 Web、业务和数据。

SQL 在不同的盒子上。

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

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

潜在地减少内存消耗

通过仅将业务层程序集添加到 Web 项目来鼓励正确的体系结构。如果数据服务也可用，那么很容易做错事

当我们将 Web 服务器从业务层和数据层分离出来时，我们就不必安装我们不需要的垃圾组件了。

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

我可以从外部角度了解这个常见问题吗？

谢谢!

Answer 1

DLL 或程序集是分发单元。

如果特定命名空间或类中的代码与另一个命名空间或类紧密耦合，那么它应该在同一个分布单元中。如果 foo.* 文件中的代码在不需要 bar.* 文件中的代码的情况下永远不会被使用，那么您也可以将它们构建到相同的分发单元中。

如果一个命名空间或一组类代表一个可重用的组件(即该代码正在两个或多个产品/应用程序中使用)，那么它是一个很好的候选者，可以单独进行版本控制并成为它自己的分发单元。

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