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?

  • 3
    What purpose is served by the decoupling? Does the coupling introduced by the serialization attributes prevent you from achieving some of your software's functional and non-functional requirements? Dec 27, 2014 at 17:03
  • @RobertHarvey The decoupling is mainly to increase static qualities like maintainability and coherence of the different parts of the system.
    – Alex
    Dec 27, 2014 at 18:33
  • I would look at it pragmatically and try and figure out which approach makes the most sense from a practical perspective. Dec 27, 2014 at 23:08
  • @RobertHarvey You mean "practical" as in functional? Surely static qualities like maintainability and cohesion is very important in software projects as well?
    – Alex
    Dec 30, 2014 at 7:12
  • Interesting downvote by the way, is this question not living up to the quality standards of programmers.se?
    – Alex
    Dec 30, 2014 at 7:15


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.