D
D
Dmitry2016-05-09 21:19:18
ASP.NET
Dmitry, 2016-05-09 21:19:18

Where should the Domain Model be?

Hello! Can you please clarify in which layer the Domain Model should be located, in the Business Layer or in the Data Access Layer?

Answer the question

In order to leave comments, you need to log in

2 answer(s)
M
Maa-Kut, 2016-05-11
@Maa-Kut

I guess in the Business Layer, because domain objects are objects that model the entities of the subject area; they include both the desired data and the appropriate behavior. In DAL, they have nothing special to do, they only need data to be stored there.

V
Valery Abakumov, 2016-05-24
@Valeriy1991

Good afternoon! DomainModel can also be placed in a separate layer (this is already a step towards the "onion" architecture (onion). For example, if the domain model strongly coincides with the models in the DAL, then it makes sense to place it in a separate VS project, set the Column, Key, ForeignKey attributes , NotMapped (and other attributes from DataAnnotations) - this is in case you have EF CodeFirst (with EF Database first this doesn’t really work - only through partial classes, but, in my opinion, this is "ugliness"), after which in the DAL layer, only the functionality of connecting to the database and executing queries will remain.If the domain model is very different from the DAL model, then you can write all sorts of wrappers that will convert domain model classes to DAL models and vice versa.
I would advise you to move the domain model to a separate project. Why? Because it's easier to use it that way. Otherwise, your business or DAL layer will turn into a garbage dump over time: there will be attributes, and exceptions, and even each layer has its own, and enum, and all sorts of services / managers / helpers / ... When splitting a solution into projects, into In my opinion, the Single Responsibility Principle (S of SOLID) should also be followed. Each project is responsible for one thing. This allows you to easily connect / disconnect functionality from other projects (it turns out something like a modular solution) and eliminates cyclic dependencies between projects (when you have a MyApp.Common project that is connected to MyApp.BLL, but in the MyApp.BLL layer there is functionality that needs to be used inside the MyApp.Common project => a cyclic dependency is obtained,

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question