目前我有一个解决方案,其层次结构如下所示。
-GUI
-ENTITIES
-DATA
-BLL
-ENTITIES
-DATA
-ENTITIES
1)这是正确的解决方法吗?我正在从GUI中删除DATA引用(只是遗留代码,我正在转移到BLL)
2)ENTITIES是否有办法从BLL或DATA调用方法?就像在Entities.Order中有Order.GetNextOrderID()从DATA调用方法?
答案 0 :(得分:1)
我将重复我对第1个问题的评论。
这是解决问题的正确方法。
“正确的方式”取决于项目。
ENTITIES是否有办法从BLL或DATA调用方法?就像在Entities.Order中有Order.GetNextOrderID()从DATA调用方法?
不是您当前的设置..您将获得循环依赖。你已经对更多的DDD方法(这就是你想要的......很好!)和一个逻辑位于实体之外的贫血领域模型感到困惑。
您应该选择逻辑的大部分位置并从那里开始工作。对于您所询问的DDD方法,实体项目将包含90%的逻辑,并且它将依赖于实体可能需要的任何其他“服务”的“BLL”项目。
Anemic Domain Model的另一面是你在BLL中有一个服务,它可以加载它所需的一切,并完成实际服务中的所有操作。那么你的实体就变成了POCO。
答案 1 :(得分:1)
1)这是正确的解决方法吗?我删除了DATA 目前从GUI引用(只是遗留代码,我正在转移到 BLL)
这是一个扩展的主题,它取决于场景。
通过组件化,与其他系统和协议集成,本机代码,多个客户端协议,移动,测试等来构建一个系统。将会有很多层,需要多个解决方案。同样的原则适用于不同的平台。
你需要考虑很多标准,所以答案是:它取决于。
但我想你正在做的事情很合适。
2)ENTITIES有没有办法从BLL或者调用方法 数据?就像在Entities.Order中一样,调用一个Order.GetNextOrderID() DATA的方法?
不,您将获得循环依赖性错误。单个模块可以做到这一点,但我不推荐它。
此外,如果要在实体中定义验证,请确保您的设计不允许在服务(bll)或数据中进行复制。如果您没有良好的团队或配对修订等,这可能会失控。
这些层的主要目的是赋予它特定的责任。如果您对图层有明确的责任,那么您应该没问题。
答案 2 :(得分:0)
好的设计是将数据层与GUI和BLL分开。这样每个层都可以执行单个任务,即GUI应该只关注用户界面,控件和视图。业务逻辑层应该只实现业务规则,数据层应该与您的数据库交互。对于第二个问题,您需要做的就是将您的数据项目的引用添加到Entity项目。希望它可以帮到你。