I currently have one separate project for my models, and one separate project for a API application that consumes this model. The intention of the separation is to avoid any outgoing dependencies from the core model to consumers like the API project, enabling me to have a nice layered structure of responsibility.
In this case though, the API can not use the model as-is, as it requires the classes to be decorated with attributes related to the serialization of the data. Since this is exactly the kind of dependencies from the model that I want to avoid, I can only see my only option being intermediate DTO's that the core model gets mapped upon.
This preserves the decoupling of the model to it's consumers, but obviously introduces some nasty redundancies where I not only manually have to create all the DTO's, but also maintain them to match an eventually changing core model. Even if AutoMapper can take care of the actual mapping.
This feels quite nasty, but since the model project is using an EDMX to define and auto generate code for the model, I'm thinking to change the t4-templates to generate an interface for every class, and using this in the consumer to put a contract on the DTO's and even let the IDE auto-implement them from the interface.
This seems quite reasonable for my, but I wonder if this would be considered a good approach for enterprise-level projects, or if I'm missing something. I guess that the extra layer of intermediate DTO's even could be seen as a good artefact in concreting a separation of the core model contract and the API contract. And if so, maybe the use of model-generated interface would conflict with this separation, even if it has some neat benefits? But in that case, maybe it would be a productive strategy to use the auto-generated interfaces where we do have an 1-to-1 mapping, and create a separate set of DTO's where the contracts actually differs?
So to be clear, I'm striving for a well partitioned and coherent architecture in order to increase general static code qualities like maintainability and cohesion. Above I gave a specific example of the partitioning of the core model from it's consumers that I try to do while rationalizing about it, and my question is whether the approach suggested could generally be considered good or not. Or could this be too specific to fit any generalized answer?
