Domain vs DTO vs ViewModel - How and When to use them?

牧云@^-^@ 提交于 2019-11-29 20:19:24

It's OK to pass the DTO to the view. If you need to change or enhance the DTO then create a ViewModel. A common scenario would be to add links. It's also OK for the ViewModel to reference the DTO as a complex property.

If you are going to have different views that require different data from your Dto it sounds like you might benefit from having different view models for these and map your Dto to these.

One of the ideas behind this is to allow greater freedom to change your view model, knowing it will not have an impact on any other part of your application. If your Dto is being used in several views then each change to your Dto would require you to test each view.

riadh gomri

See here my reply : https://stackoverflow.com/a/14059156/1288063

You say : This option seems to be the Best Practice but also seems heavy to mantain.

heavy to implement perhaps, juste few lines of code to duplicate most the time, but to maintain surely not.

To me this decision is based on where I put my validation logic.

Scenario #1: Adding a data annotation in viewmodel (in UI layer) greatly simplifies programming. Mostly there will be one on one mapping between DTO and view model. In such cases Option 1 is good. DL => DO => BL => DTO => PL => VM => V

Scenario #2) If the validation is not attached to ViewModels then DTO is replaced with ViewModel and ViewModel resides in Business layer. DL => DO => BL => VM => PL => V

Scenario #2 can be perfect in situations where validation logic resides in Domain Models. And these models are used by many UI applications. UI just lists the errors in a list, as given by the business layer (not very user friendly though). As the application undergoes business rules change we only change the domain model. Again database related validations can be auto generated through EF(if using .net), even less scope for change.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!