blocks|key|1988520|text|我通常认为域模型是一个单独的层。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1988521|如果我们看一下经典的MVC悖论，那么视图和控制器都使用该模型。|1988522|没有理由不让DAL使用它。|1988523|但是，模型不会引用DAL；对数据存储的所有操作都将由控制器完成。|1988524|所以一般的流程是-|1988525|用户与View交互View调用Controller上的方法Controller使用DAL检索Model对象Controller调用Model对象上的方法，必要时保存它们(使用DAL)，并向<代码>D9返回答案|offset|length|style|CODE|1988526|entityMap^0|0|0|0|0|0|3|4|9|4|F|A|T|A|15|3|1A|5|1H|A|1T|5|2F|3|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@$L|X|M|Y|N|O]|$L|Z|M|10|N|O]|$L|11|M|12|N|O]|$L|13|M|14|N|O]|$L|15|M|16|N|O]|$L|17|M|18|N|O]|$L|19|M|1A|N|O]|$L|1B|M|1C|N|O]|$L|1D|M|1E|N|O]]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]]|Q|$]]

I usually consider the domain model as a separate layer. 
If we look at the classic MVC paradaigm, then the model is used by both the View and the Controller. 
No reason why it shouldn't be used by the DAL as well. 

The Model, however, will not reference the DAL; all operations against the data store will be done by the controller. 

So the general flow of things would be- 
user interacts with the <code>View</code>
<code>View</code> invokes a method on the <code>Controller</code>
<code>Controller</code> uses the <code>DAL</code> to retrieve <code>Model</code> objects
<code>Controller</code> invokes methods on <code>Model</code> objects, saves them (using <code>DAL</code>) if necessary, and returns an answer to the <code>View</code>

blocks|key|1936274|text|如果你在做DDD，我相信仓库(至少是它的接口)是你的业务/域层的一部分。您的存储库实现将是一个单独的程序集，它必须引用该业务/域层。因此，您的DAL知道您的业务对象，但反过来却不知道。要进行依赖注入，您可能需要在DAL层中配置容器，以便为IRepository接口使用存储库。如果您需要一个工作模式单元，那么您的接口很可能也必须是业务层的一部分。同样，您的实现将在您的DAL中，DAL将适当地配置DI容器。这实际上是我不喜欢存储库模式的原因之一，因为您需要确保您的界面的用户正确地管理IUnitOfWork，或者您需要一些东西来包装完成此操作的存储库。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1936275|在传统的n层架构中，事情有点不同。在这种情况下，您的业务层可以与DAL通信，我通常将DAL构建为具有表示数据库中一行数据的DTO。然后，业务层将使用这些DTO来更新业务对象(或者，如果您使用的是CSLA.Net之类的东西，则业务对象知道如何更新自身的内容)。|1936276|无论哪种方式，都不应该出现以循环引用结束的情况。|1936277|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

If you're doing DDD, I believe the repository (at least the interface for it) is part of your business / domain layer. Your implementation of the repository will be a separate assembly which would have to reference that business / domain layer. So your DAL knows about your business objects, but not the other way around. To do dependency injection, you'll probably have in your DAL layer something that configures your container to use Repository for your IRepository interface. If you need a unit of work patter, your interface would likely have to be part of the business layer as well. Again your implementation will be in your DAL and the DAL would configure the DI container appropriately. This is actually one of the things I dislike about the repository pattern, as you either need to ensure your users of your interface correctly manage the IUnitOfWork, or you need something to wrap the repository which does so.

In a traditional n-layer architecture, things are a bit different. In that case your business layer can talk to the DAL, and I've normally built the DAL to have DTOs which represent a row of data in the database. The business layer will then use these DTOs to hydrate the business objects (or if you're using something like CSLA.Net, the business objects know how to hydrate themselves).

Either way there shouldn't be a situation where you end up with a circular reference.

blocks|key|5395066|text|你的BLL或域层不应该担心数据访问的技术细节，BLL应该是独立于技术的。如果你想坚持使用实体框架，你应该生成POCO实体并将它们移动到单独的层，这样你就可以避免电路引用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5395067|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Your BLL or Domain Layer should not worry about data access technical details, BLL shold be technology independent. If you want to stick with Entity framework you should generate POCO entities and move them to seperate layer, this way you can avoid circualr references.

If DbContext is in the DAL then the generic type arguments of the DbSets cannot be the BLL classes (domain model). What are the best practice ways to separate these layers? An extra model in the DAL? Interfaces?

How to avoid circular dependency: DAL.DbContext.DbSet<BLL.Model>

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

如果DbContext在DAL中，则DbSets的泛型类型参数不能是BLL类(域模型)。分隔这些层的最佳实践方法是什么？DAL中的一个额外的模型？接口？

问如何避免循环依赖: DAL.DbContext.DbSet<BLL.Model>
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何避免循环依赖: DAL.DbContext.DbSet<BLL.Model>EN