UI-centric vs domain-centric data model - pros and cons

Question

How closely does your data model map to your UI and domain model?

The data model can be quite close to the domain model if it has, for example, a Customer table, an Employee table etc.

The UI might not reflect the data model so closely though - for example, there may be multiple forms, all feeding in bits-and-pieces of Customer data along with other miscellaneous bits of data. In this case, one could you have separate tables to hold the data from each form. As required the data can then combined at a future point... Alternatively one could insert the form data directly into a Customer table, so that the data model does not correlate well to the UI.

What has proven to work better for you?

Answer 1

UI can change according to many needs, so it's generally better to keep data in a domain model, abstracted away from any one UI.

Answer 2

I find it cleaner to map your domain model to the real world problem you are trying to solve.

You can then create viewmodels which act as a bucket of all the data required by your view.

as stated, your UI can change frequently, but this does not usually change the particular domain problem you are tackling...

information can be found on this pattern here:

http://blogs.msdn.com/dphill/archive/2009/01/31/the-viewmodel-pattern.aspx