将领域模型业务实体传递给UI层问题
直接将域模型实体传递到 UI 层而不是相应的视图模型是否可以接受？
在我的示例中，UI 获取一些用户数据并将其传递给与域服务交互的演示者。领域服务对来自用户的数据执行一些操作，并将输出结果作为领域模型实体返回给 UI，通常应将其转换为视图模型。
问题是，根据检查返回结果的用户选择（Y 或 N），它可能会返回到服务以进行进一步处理，并最终保存到存储库。
如果我们不将返回的域实体保存在这两个步骤之间的某个位置，而是使用视图模型，我们将无法将其传回以进行进一步处理。
当发生此类用户交互时是否有一些解决方法？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
MVP是围绕View、Presenter和Model的概念定义的。您没有理由需要区分域实体和视图模型。它们可以（而且应该）是同一件事。与
MVVM不同，模型在绑定到View方面发挥的作用较小。演示者负责使用模型数据来操作视图。 MVP 中没有 ViewModel 的概念。该术语通常是为MVVM保留的，其中ViewModel是一个与View紧密耦合的实体，此外还有一个Model>。MVPis defined around the concept ofView,Presenter, andModel. There's no reason you need to distinguish between a domain entity and a viewModel. They can (and should) be the same thing.Unlike
MVVM, the model plays less of a role in binding to theView. It's the responsibly of the presenter to manipulate the view using the model data. There is no concept of aViewModelas such in MVP. That term is generally reserved forMVVMwhereViewModelis an entity tightly coupled toView, in addition to having aModel.我宁愿建议在视图模型方面（在 MVVM 中）将 表示模型 与域模型分开或者就 MVC / MVP 中的模型而言，因为在中到高领域复杂性中，您根据业务逻辑和面向对象的设计来设计领域模型，其具有除表示数据之外的粒度级别，当您绑定或呈现您倾向于显示的数据时的一部分域模型并将一些对象展平为大陆以进行演示。
另一个方面是，在开发分布式应用程序时，有时您需要通过服务（远程外观）公开数据，因此最好以 DTO 形式公开对象，而不是公开域模型，因为 DTO 的复杂性和复杂性不同。粒度比域模型更细，不要强迫您的域模型被破坏为表示友好或消费者友好，并且不要破坏您的表示模型和消费者以使用面向业务的域模型并增加采用它们进行表示的复杂性。
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.