开发者

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

开发者 https://www.devze.com 2022-12-08 05:15 出处:网络
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.

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 inse开发者_如何转开发rt 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?


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


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.


If I have a RESTful service layer, what they are exposing the domain model. In that case , the UI(any particular screen) calls a number of these services and from the domain models collected composes the screen. In this scenario although domain models bubble all the way up to UI the UI layer skims out the necessary data to build its particular screen. There are also some interesting questions on SO about on using domain model(annotated) for persistence. My point here is the domain models can be a single source of truth. It can do the work of carrying data , encapsulating logic fairly well. I have worked on projects which had a lot of boilerplate code translating each domain model to DTO, VO , DO and what-have-yous. A lot of that looked quite unnecessary and more due to habit in most cases.

0

精彩评论

暂无评论...
验证码 换一张
取 消