I have a logic placement dilemma, but to begin here are my app layers:
- Presentation/UI Layer (Web API or MVC, really could be anything)
- Service Layer (this layer is lean overall and acts as a conductor for Domain Model and Repository layers)
- Domain Model (this layer is not anemic, and has both data and behavior in the model classes)
- Repository
As it stands, the layers are designed well and flow is intuitive. However I have a requirement to shape the pure model data into several specific XML documents to be validated via a .xsd schema (model classes do not map 1:1 for XML document or I could just serialize object directly to XML). To me the model layer should have no understanding of being shaped or structured beyond it’s current design; that’s the responsibility of a higher layer.
My 1st thought is to provide the shaping and logic to create these XML documents from the domain model data in the Service layer via ViewModel classes to be returned up a level. I use the term here ‘ViewModel’ to purely mean shaped data for a higher layer or presentation. However, everything I read says the Service layer should not contain ViewModels: Should a service layer return view models for an MVC application? and How to pass complex ViewModel to Service Layer in ASP.NET MVC?
Ok follow this for a minute and make my MVC layer contain the ViewModels. I have a problem with this. The whole reason for having a Service layer, is the ability to act as a facade or entry point into the application, thus allowing multiple UI types (WinForms, WPF, WebForms, MVC, WCF, etc.). I need that XML shaping logic available to any UI I hook up to the Service layer. If I put it in the MVC/UI layer, it doesn’t exist anymore if I hook up a new UI.
Now I’m back to pushing the XML shaping classes back down to the Service Layer. I also don’t think these classes should be on the domain layer as this is not business logic and indicates a format type: XML, which I do not want. Lastly, I can’t introduce this logic in a vertical layer like an Infrastructure layer because now this layer has to understand my domain model and be carried around like luggage.
According to the book Professional ASP.NET Design Patterns, the following is stated when using this architecture: “The role of the service layer is to act as an entry point into the application; sometimes this is known as a facade. The service layer provides the presentation layer with a strongly typed view model, sometimes called the presentation model.” I would like to place the shaped classes in my Services layer as this seems the best fit and I have seen examples of it done this way.
Where does the logic belong? I want to take 1..n of my domain model classes, build a XML document using various data, and then allowing it to be available to the UI/Presentation layer? Thanks!
IMHO, I would say that your instinct to put these XML shaping classes into your service layer seems to be correct, It definitely doesn’t belong in the UI layer since you need it to be available to different types of UIs. Creating a separate layer for them seems like an overkill. Putting them along side your data access classes doesn’t seem right either.
I think you should go with your instinct on this one. If somewhere down the line you look at this code and you think that it’s out of place then you can simply move it to where ever you see fit. It’s nice to give it a good thought before hand, but I would say don’t get to hang up on it. Start coding and every now and then take a step back and look for things that seem out of place. Refactoring your code is something that you’ll have to do constantly as your project shape up!