UI Focused and Domain Focused Data Model - Pros and Cons
How closely does your data model map to your user interface and model?
A data model can be pretty close to a domain model if it has, for example, a Customer table, an Employee table, etc.
The user interface may not reflect the data model very accurately, although, for example, there may be several forms, all loaded into bits and pieces of Client data along with various other different bits of data. In this case, you can have separate tables to store data from each form. As needed, the data can then be merged in the future ... Alternatively, you can insert the form data directly into the Customer table so that the data model does not correlate well with the user interface.
What was best for you?
source to share
I find it cleaner to map your domain model to the real world problem you are trying to solve.
You can then create view modes that act as a bucket of all the data your view needs.
as pointed out, your UI may change frequently, but usually it doesn't change the specific domain problem you are solving ...
information can be found here:
http://blogs.msdn.com/dphill/archive/2009/01/31/the-viewmodel-pattern.aspx
source to share
If I have a RESTful service layer, then they are subject to the domain model. In this case, the user interface (any particular screen) calls a number of these services, and a screen is formed from the collected domain models. In this scenario, although the domain models are bubbling up to the UI, the UI layer dumps the necessary data to create its particular screen. There are also interesting questions on SO about using the (annotated) domain model for persistence. My point here is domain models, which may be the only source of truth. It can do data manipulation by encapsulating logic well enough. I worked on projects that had a lot of boilerplate code translating each domain model to DTO, VO, DO and whatever. Many of them looked completely unnecessary and more out of habit in most cases.
source to share