在不同的解决方案中调用方法

本文关键字：调用 方法 解决方案 | 更新日期: 2023-09-27 18:02:45

目前我有一个解决方案，它的层次结构看起来像这样。

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

1)这样布置是正确的吗?我目前正在从GUI中删除DATA引用(只是我正在移动到BLL的遗留代码)

2)实体是否有办法从BLL或DATA调用方法?就像实体一样。Order. getnextorderid()从DATA调用方法?

在不同的解决方案中调用方法

1)这样布置是正确的吗?我正在删除数据参考GUI当前(只是遗留代码，我正在移动到BLL)

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

想象一个具有组件化、与其他系统和协议、本机代码、多个客户端协议、移动、测试等集成的系统。会有很多层，需要多种解决方案。相同的原则适用于不同的平台。

你要考虑的标准有很多，所以答案是:视情况而定。

但我想它很适合你的工作。

2)实体是否有办法从BLL或数据?就像实体一样。Order. getnextorderid()调用方法从DATA?

不，你会得到循环依赖错误。一个单独的模块可以做到这一点，但我不建议这样做。

另外，如果您打算在实体中定义验证，请确保您的设计不允许服务(bill)或数据中的重复。如果你没有一个好的团队或对修订等，这可能会失控。

层的主要目的是赋予它特定的职责。如果你已经很好地定义了你的层的责任，你应该没问题。

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

这是正确的布局方式吗?

"正确的方法"取决于项目。

实体是否有办法从BLL或DATA调用方法?就像实体一样。Order. getnextorderid()从DATA调用方法?

不适合你当前的设置…你会得到一个循环依赖。您已经对更多的ddd方法(这是您想要的……))和一个贫血的领域模型，其中逻辑位于实体之外。

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

贫血域模型的另一面是，你在BLL中有一个服务，它加载它需要的一切，并在实际服务中执行所有操作。那么你的实体就变成了poco。

一个好的设计应该是保持数据层与GUI和BLL分开。因此，每一层可以执行单一的任务，即GUI应该只关心用户界面，控件和视图。业务逻辑层应该只实现业务规则，数据层应该与数据库交互。对于第二个问题，您需要做的就是将Data项目的引用添加到Entity项目中。

相关文章：