Passing domain model business entity to UI layer question

Question

Is that acceptable to pass directly domain model entity to UI layer instead of corresponding viewmodel?

In my example UI gets some user data and passes it down to presenter which interacts with domain service. Domain service performs some action on the data from the user and returns output results back to UI as domain model entity, which should be typically converted to viewmodel.

The problem is that depending on the user choice (Y or N) inspecting the returned result, it may be returned back to the service for further processing and finally saved to repository.

If we do not save returned domain entity somewhere between those 2 steps, but use viewmodel, we will not be able to pass it back for further processing.

Are there some workarounds when such user interaction takes place?

Answer 1

MVP is defined around the concept of View , Presenter , and Model . There's no reason you need to distinguish between a domain entity and a view Model . They can (and should) be the same thing.

Unlike MVVM , the model plays less of a role in binding to the View . It's the responsibly of the presenter to manipulate the view using the model data. There is no concept of a ViewModel as such in MVP. That term is generally reserved for MVVM where ViewModel is an entity tightly coupled to View , in addition to having a Model .

Answer 2

I would rather recommend separating the presentation model from domain model either in terms of view model (in MVVM) or in terms of Model in MVC / MVP, because in medium to high domain complexity you design domain model in terms of business logic and object oriented design which has a granularity level other than presentation data, when you bind or present data you tend to show part of domain model and flatten some objects to be continent for presentation.

Another aspect is when developing distributed application sometimes you need to expose your data through services (remote facade) thus it is highly preferable to expose your objects in terms of DTOs not to expose you domain model because again the aspect of DTO is different in complexity and granularity than the domain model, dont force your domain model to be corrupted to be presentation friendly or consumer friendly, and dont corrupt your presentation model and consumers to use a business oriented domain model and increase the complexity of adopting them for presentation.