这种尝试解耦图层的命令模式有多适用？

Question

在过去的项目中，我注意到许多可维护性问题源于数据访问和业务逻辑的广泛混合，以及逻辑对实体的高度依赖性。我并没有试图设计一个避免所有这一切的假设系统，但我有兴趣通过强耦合代码减少长期引入的问题。

概述（简化为仅代表手头的问题）：

• 交叉切割：实体
• 表示层：UI，使用实体显示内容，通常启动对BLL的调用
• 业务逻辑层（BLL）：与实体一起工作的逻辑，通常以静态方法实现，通常也调用DAL
• 数据访问层（DAL）：为实体提供CRUD方法的映射器（手工编码的SQL查询）

更改

我打算让所有部件更易于测试和维护。因此，我决定引入一些更改，主要是在DAL和BLL中，因为它们造成的麻烦最多。逻辑嵌入在查询中，BLL高度依赖于DAL的方法和实体。

DAL

• 引入了一种从C＃生成SQL而不是对查询进行硬编码的机制。这会导致编译时错误而不是运行时错误。我们应该能够通过这种方式更早地捕获查询和实体模型的不一致。

BLL

• 删除了对DAL的引用（完全解耦），所有逻辑都是通过一个新的“粘合”层从UI调用的，该层将UI链接到DAL和BLL。

在我看来，到目前为止一切顺利，这应该对我们来说非常好。现在是最大的改变。

• 我打算引入的另一个变化是命令模式的变体，以消除对实体模型的依赖。我还想确保业务逻辑是可测试的。因此，在我看来，“胶水”层应该将实体转换为仅包含某个逻辑需要的数据的命令对象。当模型发生变化时，只需要调整映射，业务逻辑保持不变。

这似乎是一个好主意，但我期望有大量的业务逻辑，导致需要维护大量的命令对象。这是一种合理的恐惧，还是我担心太多？你对这些问题有什么经验？

Answer 1

我真的没有看到命令模式在这里会有什么帮助。我成功地将BL与DAL分离的方法是使用外观模式。 DAL应该实现接口，并且应该通过将这些接口的实例注入其中来初始化BL。在测试BL时，您可以提供完整的模拟DAL，使单元测试变得更加容易。

Answer 2

我可以从整体设计中看到几个问题。

  

删除了对DAL的引用（将它们完全解耦），所有逻辑   从UI通过一个新的“胶水”层调用，该层链接UI   DAL和BLL。

您所指的此“胶水”图层应为Interfaces图层。一般来说，Interfaces层以可测试的方式松散地耦合各种不相关的层。

  

我打算引入的另一个变化是命令的变体   模式，以消除对实体模型的依赖。我也   想确保业务逻辑是可测试的。 Ť

看一下Repository Pattern。使用依赖注入几乎就是它解决的问题。

  

引入了一种从C＃而不是C＃生成SQL的机制   硬编码查询。

小心这个。确保你没有使用家庭酿造LINQ to SQL重新发明轮子。

要把它包起来，改变是不可避免的。没有任何模式可以使所有变更更易于管理。命令模式不会解决业务层中的范围蔓延。您最好的选择是坚持使用您已经拥有的n层解决方案，并使用您提供的最佳信息尽最大努力做出明智的设计决策。