我应该为业务逻辑创建一个 dll 还是多个 dll？

Posted 2023-02-24

【中文标题】我应该为业务逻辑创建一个 dll 还是多个 dll？

【英文标题】：Should I have one dll or multiple for Business Logic?

【发布时间】：2011-03-04 13:24:57

【问题描述】：

在我的情况下，我的公司服务于多种类型的客户。几乎每个客户都需要自己的业务逻辑。当然，会有一个所有业务逻辑都应该继承的基础层。但是，我会在架构上来回考虑——要么为所有客户使用一个 dll，要么为每个客户使用一个 dll。

我最大的争论点在于升级软件。我们有大约 12 名数据录入人员，与 20 家公司合作，他们几乎没有停机时间，这一点至关重要。我担心的是，如果我将所有内容部署在一个 dll 中，我可能会在 A 公司的逻辑中引入一个错误，而只是打算更新 B 公司的逻辑。我相信如果每个公司的逻辑都有自己的 dll，我可以降低风险，因此，我可以部署 B 公司的更新而不损害 A 公司。 -- 我将是唯一支持这一点的人。

也就是说，管理 20 个不同的 .dll 似乎也是一场噩梦——仅针对 BLL。我还需要创建一个 View 层和 ViewModel 层。因此，我可能有 20 个（公司）* 3 个（层），这相当于 60 个 .dll。

谢谢。

【参考方案1】：

如果“客户至上”，那么您必须降低一个客户代码中的错误影响另一个客户的可能性。因此更多的DLL。但是，您可以省去一些头疼的问题：真的需要将业务逻辑、视图层和视图模型层分离到不同的程序集中吗？当然，您希望将代码分成不同的层进行维护，但是是否有充分的理由将逻辑文件分离为物理程序集/DLL 分离？

【讨论】：

要回答你的问题，我不能争论分离模型/视图模型的任何一种方式，但我认为业务逻辑本质上是不同的，并且与我所研究的不同，BLL 应该始终在他们自己的 .dll 就像数据访问层一样。

什么？如何将项目拆分为纯粹由部署约束驱动的 Dll id。将代码库拆分为 Dll 几乎不能保证解耦，并且设计中逻辑上独立的模块的存在并不要求或暗示模块应该在物理上分开。将代码拆分为 Dll 既不能保证解耦，也不是大多数要求解耦的软件设计实践所要求的。