asp.net mvc - Is it ok to have database context in my domain model -

asp.net mvc - Is it ok to have database context in my domain model -

i developing web based application using asp.net mvc. trying have rich domain models rather thin/anemic models.

i have modelled solution along lines of onion architecture. different projects below :

{}.domain.core - contains domain objects , interfaces idbcontext implemented in infrastructure layer {}.database - database prject {].infrastructure - contains implementation logging, info access etc. {}.web - view , controllers

**** info access done using dapper , idbcontext wrapper around 2 simple command, query interfaces. have isolated each of queries separate class.

for sake of give-and-take taking little part of application.

i have versioned document library contains documents along other metadata tags, permissions etc

a simplified model of document object shown below

i want operations defined within domain object, since there business logic involved in each of these operations. allow me take "delete" operation. operation needs perform

validate if user has permission delete check if there no associations impacted delete check if no workflow in progress delete actual item database in transaction

as shown in above example, need database context finish operation. way have thinking if modeling have domain object have idbcontext, can execute queries exposed.

in controller class phone call domain objects , perform operations.

i not sure if passing idbcontext in domain object ok? if not improve ways model this?

i not convinced in having separate service layer because 1) controller deed first layer of service layer of cases 2) service layer duplicating same methods domain class

let me know how can improve design.

injecting idbcontext brakes main principle of domain model should responsible business logic while retrieving , storing domain entities responsibility of infrastructure layer. yes inject interface, hiding actual implementation makes domain model aware of storage.

also steps above required delete document doesn't entierly belong document object. let's consider first step user permissions , next cases:

users admin role should allowed delete document document owner should allowed delete document

for first case there might not connection between user , document remove. admin users allowed anything. it's classical illustration 2 bank accounts , operation tranfer money involves both accounts not responsibility. when domain services come place. please don't confuse them service layer services. domain services part of domain model , responsible business logic only.

so if you, create new domain service deletedocument method. should first 3 steps above accepting user , document parameters. 4th step should done repository. not sure mean saying

i didn’t see much value in adding repositories

but domain model perspective have 1 it's idbcontext. assume meant pattern implement repository or separate repository each entity. in long run pseudo code in controller should following:

var user = bdcontext<user>.selectbyid(userid); var document = bdcontext<document>.selectbyid(docid); var docservice = new documentservice(); docservice.deletedocument(document, user); // throw exception here if deletion not allowed bdcontext<document>.delete(document);

if expect need logic in many places of application can wrap in service layer service.

i suggest reading eric evans book on ddd if want larn more domain modeling. discusses meaning of entities, value objects, domain services, etc. in detail.

answer comment: not really, domain services part of domain, both implementation , interface part of domain well. fact 2 or more objects have interact each other not plenty creating domain service. let's consider flight booking scheme example. have flight entity different properties such departurecity, arrivalcity. flight entity should have reference list of seats. seat separate entity such properties class (business, economy, etc.), type (isle, row, middle), etc. booking seat requires interacting different entites, such flight , seat don't need domain service here. nature seat property makes no sense if not considered kid object of flight. it's unlikely ever have case query seat entity out of flight context. reserving seat responsibility of flight entity here , it's ok place reserving logic flight class. please note it's illustration seek , explain when need create domain services, real scheme modeled way. seek next these 3 basic steps decide whether or not need domain service:

the operation performed service refers domain concept not naturally belong entity or value object. the operation performed refers other objects in domain. the operation stateless.

i'm accessing dbcontext controller application/service layer not domain/business layer. domain model deals business logic only, should not aware of persistance logic , illustration above can see documentservice has no references of dbcontext.

asp.net-mvc oop design architecture onion-architecture