c# - How to structure projects with ASP MVC using Repository Pattern, Service Pattern, UnitOfWork, ORM (EF, NHibernate etc..) -

hi guys although seeing lots of discussions topic. cant seem find detailed answer regarding this. want know should put here , there.

where should put irepository interface. in dataaccess or in separate project "repository"?? how other abstract repositories extend irepository<> icustomerrepository : irepository ?? reside on same project? how concrete implementation of customerrepository : baserepository, icustomerrepository

and poco, should put them??

the unitofwork , service layers???

i guess know trying say...

can please , give me idea or more detailed appreciated.

ps: can services contain unitofwork can call repository? there drawback there? or why want use repository on unitofwork on services?

not definite answer, set in right direction

if plan use orm, framework have taken care of repository , uow.

here layer can begin 1) ui - 2)service agent - 3)service layer - 4)domain layer - 5)repository

client service if 1 client going use service, service layer unnecessary. may facade layer enough run in same process ui , if need comes support multiple client application, can refactored seperate service relatively less effort. abstract service calls service agent (proxy). communication ui service through agent.

if using server side mvc framework (ex: asp.net mvc), may consider viewmodel each screen. since of screens contain data different domain model (order details + shipping info + customer details in 1 screen), view model consolidate data screen specific. in case @ (.net) auto mapper mapping between dto (data service) , view models or build own light weight mapper. if planning use client side mvc ui (ex: angular) don't need design view model explicitly. whatever comes service model ui.

service backend service/facade layer - call appropriate methods on domain model. design poco (they model domain), domain model call repository crud. internally repository can use orm. if not using orm whatever reason, may have build generic code mapping data database/any other data store domain model.

define class interfaces classes in domain layer, repository , service layer(anyway framework force use interfaces services). remember design coarse grained interface on service/facade otherwise end many calls between ui , service

create separate project each layer, take 1 avg complexity use case, start implementing end end making use of layers, entity types (view models, dto, domain models), mapper (viewmodel-dto, dto-domain models). keep interfaces in separate project concrete classes project interface belongs client. ensure client not have direct dependency on concrete implementation project. identify ioc container, use inject dependencies client. ex: use di inject domain model classes in service layer. configure di inject concrete implementation in layers (service use di domain models, domain model use di repository). if use di make code against interface good. important thing refactor interface, classes, methods, structure till feel overall structure looks fine because whatever high level design implement first use case pretty become template other use cases.

once complete 1 use case, , team spend more effort in learning/designing/discussing domain model (read domain driven design eric evans - domain driven design author/creator). many things can quite confusing think start , how start. said start project each layer, add/remove refactor , refactor often.

i assume project considerable complexity.