Differences

This shows you the differences between two versions of the page.

Link to this comparison view

it:ad:patterns:dto_strategy [2019/03/24 12:17] (current)
Line 1: Line 1:
 +# IT:​AD:​Patterns:​DTO Strategy #
  
 +
 +
 +<callout type="​Navigation"​ class="​small">​
 +* [[../​|(UP)]]
 +{{indexmenu>​.#​2|nsort tsort}}
 +
 +
 +</​callout>​
 +
 +
 +## Summary ##
 +
 +
 +
 +It/​all/​depends/​on/​how/​you/​architect/​your/​application. ​ If you have a complex business model, you may want to look into domain-driven-design. ​ If your model is simplistic maybe a simple 2 or 3-layer (UI,​BLL,​DAL) will be sufficient. If your model can easily be reflected in your UI then maybe look into NakedObjects. ​
 + 
 +Chances are, however, your DTOs should almost never be mirrors of your business model. ​ Your DTOs should be customization'​s of closely-related data - associated & particular to a specific context. ​ For instance a specific user interface can be represented by a ViewModel which is composed of multiple DTOs.  Your Web API services may provide endpoints for these DTOs.  This doesn'​t mean that it's wrong to have a DTO that resembles an EF model object but DTOs can be composed of richer data than 1:1 mappings.
 + 
 +It also depends on the amount of loose-coupling your trying to achieve with your architecture. ​ Is your business logic going to communicate with the database directly through EF's DbContext? ​ In that case your BLL and DAL are indeed one layer. Not that extensible, but it may provide you with a better ROI if your time-to-market is of high importance. ​ If you want a better seperation of concerns, you may decide to adopt the repository pattern, thus abstracting your data-access - which in the future can be easily replaced without touching the business logic.
 + 
 +Your DTOs should only be immutable bags of getters/​setters.
 + 
 +Your domain model (EF POCOs) or business layer model should be more complex. ​ This is where customizing the EF T4 POCO template becomes incredibly powerful. ​ Make your EF POCOs partial classes so they can be extended to contain business logic, validation, cross-cutting concerns, etc etc.
 + 
 +I should also add you can expose your EF model via Web API and make use of OData. ​ Unfortunately I don't have much expertise with that and maybe the community here can elaborate when to use this?
 +
 +
 +Note: I would take that as more of a philosophy. DTOs are meant only to transfer data between applications. The data shouldn'​t change at any point, once set.
 +
 +Ref: [http://​forums.asp.net/​p/​1818473/​5048008.aspx/​1?​Re+Map+DTO+in+a+EF+entity+using+JSON+NET](http://​forums.asp.net/​p/​1818473/​5048008.aspx/​1?​Re+Map+DTO+in+a+EF+entity+using+JSON+NET)