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