2

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

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

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

变化

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

达尔

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

BLL

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

在我看来，到目前为止一切都很好，这对我们来说应该很好。现在是最大的变化。

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

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

4

2 回答 2

1

我可以看到整体设计存在几个问题。

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

您所指的这个“胶水”层应该是一个Interfaces层。一般来说，接口层以可测试的方式松散地耦合了各种其他不相关的层。

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

查看存储库模式。使用依赖注入，这几乎就是它所解决的问题。

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

小心这个。确保您没有使用 home brew LINQ to SQL 重新发明轮子。

总而言之，变化是不可避免的。没有任何模式可以让所有变更更易于管理。命令模式不会解决业务层中的范围蔓延。您最好的选择是坚持您已有的 n 层解决方案，并根据您现有的最佳信息，尽您最大的能力做出明智的设计决策。

于 2013-11-11T21:11:50.333 回答
1

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

于 2013-11-11T21:06:22.077 回答