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

Question

在我见过的大多数MVP示例中，演示者调用某个服务，该服务调用某个存储库，该存储库返回一个实体。在我开发过的大多数asp.net web应用程序中，逻辑从来没有那么简单。在我的上一个项目中，我的演示者调用了一个演示者服务层，该服务层必须经过层层筛选才能获得要在屏幕上显示的数据。

Details:服务层向数据库查询，比方说，8个实体对象，其中一些彼此嵌套，然后代码将这些实体映射到一个基于XSD的大型对象。然后将该xsd对象传递给第三方库来处理它。在它返回处理过的xsd对象之后，代码必须解析该xsd对象，使用中间层视图格式化器类提取并构建我称之为"视图模型"(我听说有人称之为DTO)的东西。这个视图模型然后从服务层返回给呈现者，然后绑定到中继器。

1. 显示/隐藏控件的逻辑在哪里?它应该是DTO中的成员吗?还是表示者应该派生这个值?(我选择将其作为视图模型中的成员)
2. 是否可以有嵌套的视图模型(dto)或其他用户控件被用来打破复杂性?
什么是连接演示器与所有使用它的页面/用户控件的好方法?这意味着一个演示器有5个iview，它们需要演示器的相同实例。用户控件应该是自包含的，还是应该依赖于"父"IView(页面)来给它适当的演示器?

3. 与其使用视图模型，为什么不直接使用页面实现的接口，并将其传递给服务层(通过呈现者)，让服务为IView提供支持呢?(这样做会导致服务层有一个对它的引用，不是很糟糕吗?)

   public class ViewModel
   {
       public bool ShowHeight { get; set; }
       //Is there a bettter way to do this?
       public List<NestedViewModel> NestedViewModel { get { return _nestedViewModel; } }
   }
   

Answer 1

1. 在我看来，视图应该在显示和隐藏方面进行自我管理;它是视图，负责管理UI行为。
2. 我认为复杂是可以的，只要它不是太霸道;如果你需要的话，你可以把它分解成嵌套的子演示器/视图。
3. 大多数MVP框架从视图中填充演示者/视图关系，特别是自从ASP。. NET在该页的上下文中运行(该页是处理请求的HTTP处理程序，因此该页是活动的)。在初始化过程中，页面进入并建立视图/呈现者关系。大多数例子都是这样做的。我建立了一个MVP框架，也建立了这种方法。
4. 你可以;这被认为是被动视图，尽管呈现者仍然应该完成工作，而不是直接传递给服务层。

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