Last post Sep 18, 2016 08:48 PM by Mikesdotnetting
Sep 18, 2016 04:40 PM|Fouad Roumieh|LINK
I'm working on a project that is following the DB first approach and EF is used for persistance. So we have an edmx file that generates the entity objects, but on top of that we are creating Domain Objects classes that maps to the EF objects which in turn
maps to the DB. Also on top of DO we are creating DTOs that are passed to the application layer via the repository methods and those methods are accessed via the services layer from the controller actions.
I'm seeing that the DO objects that we are creating are useless and they are nothing more than a replication of the EF classes, is this true? and what can be a better approach to design this?
Sep 18, 2016 08:48 PM|Mikesdotnetting|LINK
If you start with the database, you cannot be using DDD by definition. If you are creating domain objects that are basically no more than copies of the objects defined in the edmx, you should consider getting rid of the edmx file altogether and using a code
first approach. That way you can practice DDD.
Repositories normally return domain objects. The only time I return something else is if I want to return a projection - a subset of the data represented by the entity.
DTOs are intended to be used to represent data being transferred across processes - e.g. by Web-based APIs. There is no place for them purely within the confines of an MVC app. The only other type of object you should define is a view model - an object that
represents all the data required for a view.