在 MVP 中，如何处理数据模型复杂性以及在何处动态显示/隐藏控件？

发布于 2024-11-27 23:51:32 字数 865 浏览 7 评论 0原文

在我见过的大多数 MVP 示例中，演示者调用某个服务，该服务调用某个存储库，该存储库返回一个实体。在我开发过的大多数 ASP.NET Web 应用程序中，逻辑从来都不是那么简单。在我的上一个项目中，我的演示者调用了演示者服务层，该层必须跳过重重困难才能获取要在屏幕上显示的数据。

详细信息：服务层在数据库中查询 8 个实体对象，其中一些实体对象相互嵌套，然后代码将这些实体映射到 XSD 的一个巨大对象库。然后将该 xsd 对象传递给第三方库以对其执行某些操作。返回处理后的 xsd obj 后，代码必须解析该 xsd 对象，使用中间层视图格式化程序类来提取和构建我所说的“视图模型”（我听说有人称其为 DTO）。然后，该视图模型从服务层返回到呈现器，然后将数据绑定到转发器。

显示/隐藏控件的逻辑在哪里？该值应该是 DTO 中的成员还是演示者应该导出该值？（我选择将其作为视图模型中的成员）
可以嵌套 ViewModel（DTO）还是应该使用其他用户控件来分解复杂性？
将演示者与使用它的所有页面/用户控件连接起来的好方法是什么？这意味着一个演示者有 5 个 IView，需要相同的演示者实例。用户控件应该是自包含的还是应该依赖“父”IView(page) 来为其提供适当的演示者？
为什么不直接使用页面实现的接口并将其传递给服务层（通过演示者）并让服务水合 IView，而不是使用视图模型？（这样做会导致服务层引用它，这不是很糟糕吗？）。
```
公共类ViewModel
{
    公共布尔显示高度{获取;放; }
    //有更好的方法吗？
    公共列表 NestedViewModel { 获取 { 返回 _nestedViewModel; } }
}
```

原文

In most of the MVP examples I've seen, the presenter calls some service, which calls some repository, which returns an entity. In most asp.net web applications that I have worked on, the logic is never that simple. In my last project, my presenter called a presenter service layer that had to jump through hoops to get the data that was to be shown on the screen.

Details: The service layer queries a database for, let's say, 8 entity objects, some of which are nested within each other, then the code maps those entities to one huge object base off of an XSD. That xsd object was then passed to a 3rd party library to do something with it. After it returned the processed xsd obj, the code then had to parse through that xsd object, using a middle layer view formatter class to extract and build what I call the "View Model" (I've heard some call it a DTO). This View model was then returned from the service layer to the presenter and then databound to a repeater.

Where does the logic for show/hide controls go? Should that be a member in the DTO or should the presenter derive this value? (I chose to have it as a member in the view model)
Is it ok to have nested ViewModels(DTOs) or should other user controls be used to break down the complexity?
What is a good way to wire up a presenter with all of the Pages/UserControls that use it; meaning one presenter with 5 IViews that require the same instance of the presenter. Should user controls be self contained or should they rely on the "parent" IView(page) to give it the proper presenter?
Instead of having a view model, why not just use the Interface that the Page implements and pass that to the service layer (through the presenter) and let the service hydrate the IView? (Doing this would cause the service layer to have a reference to it, isn't that bad?).
```
public class ViewModel
{
    public bool ShowHeight { get; set; }
    //Is there a bettter way to do this?
    public List<NestedViewModel> NestedViewModel { get { return _nestedViewModel; } }
}
```

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

夜空下最亮的亮点 2024-12-04 23:51:32

IMO，视图应该自行管理显示和隐藏；它是视图，负责管理 UI 行为。
我觉得复杂一点是可以的，只要不是太霸道即可；如果需要，您可以将其分解为嵌套的子演示者/视图。
大多数 MVP 框架从视图中填充演示者/视图关系，特别是因为 ASP.NET 在页面上下文中运行（页面是处理请求的 HTTP 处理程序，因此它在此时处于活动状态）。页面在初始化期间建立视图/演示者关系。大多数例子都是这样做的。我建立了一个MVP框架，也建立了这个方法。
你可以；这被认为是被动视图，尽管演示者仍然应该完成工作，而不是直接传递到服务层。

这是我的观点，有很多方法可以做到这一点。

回复收藏 0 原文

~没有更多了~