Application Architecture Advice

1
votes

I have been studying various patterns for layering an MVC application and need a little advice. What I currently have is the following:

1) POCO Domain Model, no business logic at all, so basically an anemic Domain Model.
2) EntityFramework with a Repository layer that hands back Domain objects.
3) Service Layer, now I am not sure if this an Application Service Layer or Domain Service Layer, but basically it is an API against the domain model. All of the business logic resides in this layer and assures the domain objects are valid, then hands it off to the repositories to be persisted via EF back to the DB.
4) ASP.NET MVC Application, this application talks to the service layer to get the objects it needs.

I like how this works as it provides a single point of interaction with the domain model, but what I think I need is a layer in between the service layer and the mvc application. The responsibility of this layer would be to transform domain objects to and from view models that the controller could interact with to get the exact data the view needs, and to provide the populated domain objects back to the service layer. Would this be the Application Service Layer and the service layer mentioned above is the Domain Service Layer?

I use AutoMapper to get the domain objects into view models, but I am not sure of the standard of getting them back to a domain object.

Any advice or ideas would be great.

1
asp.net-mvc-3architecturerepository-patternservice-layer
This description is kinda long on buzzwords and short on details. Even if you fleshed it out, though, it's not the kind of question that fits well on SO. As a design question, it's a bit too open-ended and subjective. - cHao
+1 Even though I don't think this question falls strictly within SO's guidelines for what a good question should be (e.g. very broad with no sample code), I'm voting it up anyway. I struggle with these exact same questions and I hope you get some good responses. - Dan A.

1 Answers

1
votes

While in theory, your Domain Layer (especially if you are using POCOs) classes are perfectly fine to use in Controllers and Views, in practice, there are always these corner cases and differences. Typically, objects that controllers and views deal with are simplifications of your Domain Model POCOs or different aggregations of your POCOs from what your Application Service Layer provides/understands.

Therefore, I would not recommend building a separate layer and instead I would recommend adding methods to your View Models to your Domain Layer objects to be sent to your Application Service.

For example, if you have User Domain Level class and UserModel View Model, I would advocate creating User ToUser() instance method on and UserModel UserModel.FromUser(User user) static method to deal with conversion. You can also mix and match other View Models in there to be able to create Domain Objects.