查看遗留应用程序的架构，我发现使用了 3 层模式。问题是域或业务类继承自数据层类，这是我以前见过的。我总是引用业务类中的数据层对象来调用它们。
我看不到以这种方式实现架构的目的，我认为它打破了关注点的分离，但我不知道我是否遗漏了什么。
你有没有遇到过类似的事情？是否有充分的理由说明为什么或为什么不进行这种继承？
问问题
196 次
2 回答
1
问题是域或业务类从数据层类继承......是否有充分的理由说明为什么或为什么不进行这种继承
如果你想在业务层和数据层之间有一个清晰的分离（任何好的、灵活的系统都会这样做），那么这种方法对我来说肯定是有味道的。
我可以为这种继承类型给出的唯一理由是必须保证后端永远不会更改更改，并且 DAL 将始终使用与域相同的定义。通常，对于 DDD，事物的无处不在的语言方面被限制在域中，并且在 DAL 中不应该真正成为一个问题。
总之，我想说就灵活性而言，这不是一个很好的方法。但是，我不能说这是否是一个糟糕的设计，因为这完全取决于该特定系统的上下文。
于 2013-11-04T12:04:47.550 回答
0
正如您所说，它是一个遗留应用程序。因此，架构不能遵循今天的期望，尤其是在可维护性方面。此外，似乎代码没有测试单元。
当前架构存在许多缺点。但是从业务角度来看，该设计对于 CRUD 操作和存储过程数据库逻辑是有效的。通常在 CRUD 操作中，处理流程定义如下：
输入（UI）-> 插入 DAL
请求 (UI) -> 从 DAL 获取记录 -> 返回 UI
这使得将关注点与 BLL 和 DAL 分离似乎有点矫枉过正（我的同行实际上是这么说的）。此外，当您的数据存储有自己的逻辑（存储过程）时，流程无需 BLL 直接进入 DAL。因此，完全删除 BLL 是有效的。
有关这种不同的架构愿景的更多信息，这里有一篇有趣的文章，
于 2013-11-04T13:41:15.320 回答