logo标签列表

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

.netarchitecturecom+
8
在我的公司，有一场辩论正在进行。一些人主张将业务、数据和业务实体放在一个程序集中，以便于发现和查找。减少需要添加到项目中的dll数量。而其他人则引用应用程序架构指南，希望每个层和业务实体都在单独的程序集中。
请注意：
我们的业务和数据层都由COM +组件组成。
我们当前的硬件架构在同一台机器上有Web、业务和数据。
SQL在另一台机器上。
我们目前没有使用DLL版本控制，因为对于COM+来说这基本上是无用的。
我们中的一些人有一种直觉，认为我们应该分离我们的业务、数据和实体，但缺乏理由。
潜在地减少内存消耗。
通过仅将业务层程序集添加到Web项目中来鼓励正确的架构。如果数据服务也可用，则很容易以错误的方式处理事情。
当我们将Web服务器从业务和数据层分离时，我们将不必从一个庞大的程序集中安装我们不需要的东西。
现在我们的系统中有大约600个DLL。所以我们处于一个极端，在那里一切都被拆分了。肯定可以进行一些整合，但被提出的方案将把我们带到完全不同的极端，即每个应用程序都在一个DLL中。
我能否得到一些外部的观点来解决这个常见问题？
谢谢！
3个回答
4
DLL或程序集是分发的单位。
  1. 如果特定命名空间或类中的代码与另一个命名空间或类紧密耦合，则应将其放在同一分发单位中。如果foo.*文件中的代码没有不需要bar.*文件中的代码，那么可以将它们构建到同一分发单元中。
  2. 如果命名空间或类组表示可重用的组件（即该代码正在两个或多个产品/应用程序中使用），则可以将其作为单独的版本并成为自己的分发单位。
对我来说，这主要涉及内聚性、耦合度和重用性。
我喜欢特定分发单元中的类具有内聚性，我不喜欢分发单元之间的耦合（我几乎总是更喜欢依赖于包含接口的第三个分发单元，以便通过对抽象而不是具体的依赖实现耦合）。对我而言，重用是做出关于分发单元决策的关键因素。如果代码将在多个应用程序/产品中使用，则需要将其作为单独的分发单元，并具有自己的版本号，该版本号与应用程序版本号分开。
2
分割物理部署边界是个好主意。如果您有可以用于远程使用的组件，则分开一个程序集是有意义的。对于初学者来说，这可能是最简单和最可靠的分割线。例如，在某些情况下，您不希望Web层包含业务服务和数据访问代码。
从那里开始，尝试将程序集减少到可以独立版本控制的内容。如果您总是需要一起复制10个程序集，则它们可能应该构建为一个程序集。
1

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

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

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接