回顾遗留应用程序的架构，我发现使用了3层模式。问题是域或业务类继承自数据层类，这是我以前见过的。我总是引用业务类中的数据层对象来调用它们。
我无法看到以这种方式实现架构的目的，我认为它打破了关注点的分离，但我不知道我是否遗漏了某些东西。
你有没有遇到过类似的东西？为什么或为什么不进行这种继承有充分的理由吗？答案 0 :(得分：1)
问题是域或业务类是从数据层类继承的......有没有理由说明为什么或为什么不进行这种继承
如果您希望在业务层与业务层之间实现 clean 分隔。数据层（任何好的，灵活的系统都会）然后这种方法肯定闻到我的味道。
我可以为这种类型的继承提供的唯一理由是必须保证后端不会改变更改，并且DAL将始终使用与域相同的定义。通常使用DDD，无处不在的语言方面受到域限制，并且不应该成为DAL中的关注点。
总之，我认为这不是一个关于灵活性的好方法。但是，我不能说它是否是糟糕的设计，因为它完全取决于特定系统的上下文。
答案 1 :(得分：0)
正如您所说，它是一个遗留应用程序。因此，架构必须遵循今天的期望，特别是对于可维护性。此外，似乎代码没有测试单元。
目前的架构存在许多缺点。但是从业务角度来看，该设计对于CRUD操作和存储过程数据库逻辑是有效的。通常在CRUD操作中，流程定义如下：
输入（UI） - ＆gt;插入DAL
请求（UI） - ＆gt;从DAL获取记录 - ＆gt;返回UI
这使得BLL和DAL的关注分离似乎有些过分（我的同行实际上已经说过了）。此外，当您的数据存储具有自己的逻辑（存储过程）时，流程将直接转到DAL而不使用BLL。所以删除BLL是有效的。
有关这种不同的架构愿景的更多信息，有an interesting article here，