c# - 在这种解耦层的尝试中，命令模式的适用性如何？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 提供事实和引用来回答它.

3年前关闭。




Improve this question




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

概述 (简化为仅代表手头的问题):

横切:实体

表示层:UI，使用实体显示内容，通常发起对 BLL

的调用

业务逻辑层 (BLL):与实体一起工作的逻辑，通常实现为静态方法，通常也调用 DAL

数据访问层 (DAL):为实体提供 CRUD 方法的映射器(手动编码的 SQL 查询)

变化

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

达尔

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

BLL

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

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

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

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

Answer 1

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