Question

目前我有一个解决方案，其层次结构如下所示。

-GUI
 -ENTITIES
 -DATA
 -BLL
  -ENTITIES
  -DATA
   -ENTITIES

1）这是正确的解决方法吗？我正在从GUI中删除DATA引用（只是遗留代码，我正在转移到BLL）

2）ENTITIES是否有办法从BLL或DATA调用方法？就像在Entities.Order中有Order.GetNextOrderID（）从DATA调用方法？

Answer 1

我将重复我对第1个问题的评论。

这是解决问题的正确方法。

“正确的方式”取决于项目。

ENTITIES是否有办法从BLL或DATA调用方法？就像在Entities.Order中有Order.GetNextOrderID（）从DATA调用方法？

不是您当前的设置..您将获得循环依赖。你已经对更多的DDD方法（这就是你想要的......很好！）和一个逻辑位于实体之外的贫血领域模型感到困惑。

您应该选择逻辑的大部分位置并从那里开始工作。对于您所询问的DDD方法，实体项目将包含90％的逻辑，并且它将依赖于实体可能需要的任何其他“服务”的“BLL”项目。

Anemic Domain Model的另一面是你在BLL中有一个服务，它可以加载它所需的一切，并完成实际服务中的所有操作。那么你的实体就变成了POCO。

Answer 2

1）这是正确的解决方法吗？我删除了DATA 目前从GUI引用（只是遗留代码，我正在转移到 BLL）

这是一个扩展的主题，它取决于场景。

通过组件化，与其他系统和协议集成，本机代码，多个客户端协议，移动，测试等来构建一个系统。将会有很多层，需要多个解决方案。同样的原则适用于不同的平台。

你需要考虑很多标准，所以答案是：它取决于。

但我想你正在做的事情很合适。

2）ENTITIES有没有办法从BLL或者调用方法数据？就像在Entities.Order中一样，调用一个Order.GetNextOrderID（） DATA的方法？

不，您将获得循环依赖性错误。单个模块可以做到这一点，但我不推荐它。

此外，如果要在实体中定义验证，请确保您的设计不允许在服务（bll）或数据中进行复制。如果您没有良好的团队或配对修订等，这可能会失控。

这些层的主要目的是赋予它特定的责任。如果您对图层有明确的责任，那么您应该没问题。

Answer 3

好的设计是将数据层与GUI和BLL分开。这样每个层都可以执行单个任务，即GUI应该只关注用户界面，控件和视图。业务逻辑层应该只实现业务规则，数据层应该与您的数据库交互。对于第二个问题，您需要做的就是将您的数据项目的引用添加到Entity项目。希望它可以帮到你。