8

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

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

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

请注意

  • 我们的业务层和数据层都由 com + 组件组成。
  • 我们当前的硬件架构在同一个盒子上拥有 Web、业务和数据。
  • SQL 在不同的盒子上。
  • 我们目前没有使用 dll 版本控制，因为无论如何它对 com+ 几乎没有用处。

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

  • 潜在地减少内存消耗
  • 通过仅将业务层程序集添加到 Web 项目来鼓励正确的体系结构。如果数据服务也可用，那么很容易以错误的方式做事
  • 当我们将 Web 服务器与业务层和数据层分开时，我们将不必安装我们不需要的垃圾组件。

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

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

谢谢！

4

3 回答 3

4

DLL 或程序集是分发单元。

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

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

于 2009-03-30T21:08:30.423 回答
2

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

从那里开始，尝试将程序集简化为对独立版本有意义的东西。如果您总是需要一起复制 10 多个程序集，那么它们可能应该被构建为一个程序集。

于 2009-03-30T21:13:59.320 回答
1

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

我们不会特意将代码塞入它不属于的程序集中。但我们绝对不会在没有充分理由的情况下创建新程序集。通常，我们有一个用于应用程序共享逻辑（业务对象等）的程序集和一个用于用户界面的程序集（Web 程序集、WinForms 程序集等）。我们也不会为了避免创建新的程序集而在程序集之间复制代码/类。

于 2009-03-30T21:10:54.507 回答