Entity Framework Repository Design, multiple instances of IUnitOfWork in multi-level loop -

i using entity framework , repository unit of work design pattern.

sometimes unit of work, making other calls different service.

this service in turn making own unit of work instance, example:

isettingsservice settingsservice = unitycontainer.resolve<isettingservice>(); using (iunitofwork unitofwork = unitofworkfactory.createunitofwork()) {     list<company> companies = unitofwork.companiesrepository.getall();     foreach(company company in companies)     {         settingsservice.savesettings(company, "value set");         company.processed = datetime.utcnow();     }     unitofwork.save(); }  // isettingsservice.savesettings code in module... isettingsservice.savesettings(company company, string value) {     using (iunitofwork unitofwork = unitofworkfactory.createunitofwork())     {         setting setting = new setting();         setting.companyid = company.companyid;         setting.settingvalue = value;         unitofwork.insert(setting);         unitofwork.save();     } } 

the above code work, have reference id's explicitly rather attaching company object (it throw error being tracked other unit-of-work in other service).

as far can tell see 3 ways of happening:

1) use code as-is service layers creating own unit-of-work instances, other references other entity's done on primary key basis (procedures set values should passed primary key object value, i.e. int customerid).

the bad side potentially more hits database, , if entity primary key type changed, need change service layer references id field. __

2) have service layers accept entity objects references. nice pass objects around.

the bad side entities must not referenced other context , must attached context used. in loop, entity attached. __

3) pass in unit-of-work instantiations other service layers can use existing unit-of-work instead of instantiating own.

not sure there downside other having pass around unit-of-work reference, upside ability reference objects without having attach them or worry if attached. __

in summary, need standardize on 1 access design, , appreciate recommendations on 1 should choose.

in addition there transactions need concerned or entityframework unit-of-work design pattern implementing form of transactional processing implicitly changed committed on context.save(), or mistaken?

thanks,

chris

you have few options amongst them:

1. have different services pass out dettached entities (its entities), perhaps dtos not entities, have each service translate them entities (or use primary keys).
   

   each service can create own content , use own edmx or shared emdx (or several edmxs).

2. if services using same edmx, inject same context them (you can wrap behind , interface don't expose ef).

3. if services don't use same edmx, either:

   3.1. go option 1, using different entities different services (or dtos).

   you can "share" tables between edmxs using different entities or use views "tables external domains" reflect read-only version of tables other domains.

   3.2. create master edmx merging edmxs 1 big 1 (see this question details)

changes applied when calling context.acceptchanges(), can save changes multiple contexts, accept changes in each after saves have completed.