CODEWITHSUNDEEP
c#entity-frameworkarchitectureinterfacedependency-injection
Benjamin
Benjamin

Reputation: 3234

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

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?

Upvotes: 1

Views: 690

Answers (3)

Brainchild
Brainchild

Reputation: 1884

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.

Upvotes: 0

Andy
Andy

Reputation: 8562

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.

Upvotes: 3

J. Ed
J. Ed

Reputation: 6752

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 View View invokes a method on the Controller Controller uses the DAL to retrieve Model objects Controller invokes methods on Model objects, saves them (using DAL) if necessary, and returns an answer to the View

Upvotes: 1

Related Questions