c# - How do I add a service layer to my UnitOfWork using Ninject? -

i hit little road block trying set di.

so given have controller:

public userscontroller(iunitofwork unitofwork) {    // stuff } 

i had unitofwork implementation accessed repositories directly.

public class unitofwork : iunitofwork, idisposable {   private readonly dbcontext _context = new dbcontext();    public irepository<user> users { { return new userrepository(_context); } } } 

ninject unitofwork code: bind<iunitofwork>().to<unitofwork>().inrequestscope();

now works fine. want change instead of unitofwork containing repositories, contains services take in multiple repositories.

public class userservice : iuserservice {   private readonly iuserrepository _userrepository;   public userservice(iuserrepository userrepository, /* other repositories */)   {     _userrepository = userrepository;   } } 

right solution can come is

public class unitofwork : iunitofwork, idisposable {   private readonly dbcontext _context = new dbcontext();    public iuserservice userservice   {         {       return new userservice(new userrepository(_context), /* etc. */);     }   } } 

this doesn't seem right. i'm creating of service dependencies myself.

i've seen posts on stackoverflow mentioning it's better have services access multiple repositories , handle business logic rather having controller (mvc application) worry it.

can't find specifics on how though. how use ninject i'm after?

sorry, overgrown comment hey...

a dbcontext is a unit of work, , creating monster unit of work straddles 2 dbcontexts not general pattern (hence question sez you)

the comments on answer here related question stray same territory.

questions ask before try solve way:

• what attempting accomplish unit of work of mine beyond having dbcontext?
• does need transactional?
• is there missing service in middle should have own data references 2 other ones?
• does need straddle 2 bounded contexts? if need pull them part again later?
• if had 3 cases of in app keep merging them 1 bc? 4?

for me crux creating own uow wrap uow:

1. doesn't buy
2. makes harder reason core problem

---

if still going shoehorn stuff in ninject in way, technical approach use context preservation , factory extensions - go read examples in wikis. if decide strip things back, still have parts play too.

update: catch drift - it's important link stuff guiding thinking front. first, go read this. next, decide if you're going have unit of work. if so, , going commit , dispose it?

if repositories and/or services going share either uow or dbcontext , going centrally commit stuff, bind things shared/disposed inrequestscope have a) single shared instance b) disposal

my main concern remains whether these abstractions benefiting things - writing tests use abstractions (and not first few)? going switch repositories. go read ddd book few times better time investment.

i realise lot of highly patronising , simplified question representing part of larger problem, i've seen many questions prompted intersection of wrapping layers , di container trickery hence rant. rant complete, thanks!