CODEWITHSUNDEEP
entity-frameworkrepositorypocoasp.net-mvc-4unit-of-work
danmanallen
danmanallen

Reputation: 175

Architecture Design - MVC, EF, Rep, UoW, WCF, DI

Architecture Design

Looking for some suggestions for a new architecture that I am putting together.

Tools to use:

Any other good tools let me know.

Firm on using EF for ORM with NHibernate being a second go to if EF proves unworthy.

What I have done so far

1) Presentation Project (MVC4, DI For services, Service Channel setup, View Models) -> references Domain Project (2)

2) Domain Project (POCO Entities, Domain Objects, Service Interface) -> References Business Project (3)

3) Business Project (WCF Service, Concrete Service Classes, Unit of Work) -> References Data Project(4)

4) Data Project (EF, Context + .edmx, Repositories and their interfaces) -> Looks at database

Question 1: Is this a good project breakdown? Question 2: Is this a good place to put any of the mentioned items in the parentheses? Question 3: Is there anything that should be somewhere that I have entirely left out?

A few side notes: We have large record sets that we retrieve that easily exceed 100,000 records. Rather than going through a WCF service we are just calling a concrete service class that will increase performance. We topped out the max message size plus it took twice as long to retrieve records through WCF.

Question 4: Is there a better method to go about doing this? Performance is key. Reusability is not

Domain objects have a single attribute which is whatever POCO that it corresponds to. Example: I have a domain object called “Order”. It has a single attribute of “OrderPOCO” which holds all of the attributes. The domain object then has validation methods and references the necessary CRUD functions.

Question 5: Where should complex validation such as “does this record already exist” be placed? Can it just be done in the service itself?

Question 6: Are Domain object even necessary? Most other examples don’t have domain models if they are using POCO’s from what I can tell. Just a little confused on the idea.

Sorry this is very long. Any answer will be greatly appreciated but a comprehensive answer will be exponentially more helpful. We can pick tools to do different things but making them work together correctly is the hard part.

Criticism welcome!

Thank you all

Upvotes: 2

Views: 1102

Answers (1)

ThomasH
ThomasH

Reputation: 526

Question 1, 2 and 3: I've often seen architecture layouts containing only three layers. But if you want to keep your Domain Project layer and Business Project layer seperated and decoupled, so you can change one without affecting the other you should of course keep them in seperate assemblies. However POCO entities, unit of work and concrete service implementations are often very closely related to the domain and to the business rules of your application, so you could consider merging these two layers into one assembly.

I would move the reposiroty interfaces up in the businnes layer, remove the reference from busines layer to data layer, and have the UI layer reference the data layer instead. The UI layer then constructor injects the concrete repostiories into the domain/business layer. This keeps your domain/business layer clean of references to the technology dependent data assembly.

Question 4: If performance is important, I would just call the concrete service classes.

Question 5: I'm not sure what you mean by "complex validation".

Question 6: EF can auto-generate the POCOs for you and place them in another assembly than the .edmx. See this article. This way your POCOs only depend on the T4 template and are not hard coupled to the EF.

Upvotes: 2

Related Questions