根据 MVVM 模式 — 谁负责

本文关键字:MVVM 模式 根据 | 更新日期: 2023-09-27 17:56:58

根据MVVM,模型内部应该没有逻辑。假设有一个包含两个属性的 Person 模型:

public class Person {
    public string Costcenter { get; private set; }
    public User User { get; private set; }
}

User 对象本身包含一个 Other Person 对象,该对象在其他属性中包含一个属性"Costcenter"。

public class User {
    public OtherPerson Person {get; private set; }
}
public class OtherPerson {
    public string Costcenter {get; private set; }
}

他者是与完全不同的阶级

现在我的实际问题:谁将负责检查Costcenter in Person是否等于OtherPerson中的Costcenter?

Person.Costcenter == Person.User.OtherPerson.Costcenter

没有太多的可能性:

  1. 视图模型负责
  2. 可以在模型中实现小段代码
  3. 检查可以作为 getter 属性实现

public ViewModel(){
    [...]
    public bool IsCostcenterEqual(Person p){
        return p.Costcenter == p.User.OtherPerson.Costcenter;
    }
}

public class Person {
    public string Costcenter { get; private set; }
    public User User { get; private set; }
    public bool CostcenterEquals(){
        return this.Costcenter == this.User.OtherPerson.Costcenter;
    }
}

public class Person {
    public string Costcenter { get; private set; }
    public User User { get; private set; }
    public bool IsCostcenterEqualProperty{
        get{
            return this.Costcenter == this.User.OtherPerson.Costcenter;
        }
    }
}

在这一点上,我不确定这是否只是一个意见问题,但我正在寻找解决此问题的最佳*方法

*) 最佳 = 与 MVVM 模式相关的最佳拟合

编辑 1

我忘了提到我想使用我的 EF 模型(如果这很重要)

根据 MVVM 模式 — 谁负责

我认为你这里的课程比你想象的要多。您的 ViewModel 类正在执行与 MVC 中的控制器类似的工作。它们不应该包含任何业务逻辑,但它们应该协调具有业务逻辑的类,即您的应用程序逻辑。

因此,我们有"应用程序逻辑",

它控制UI,将数据绑定到视图,并在用户执行的操作/看到的内容与实现其规则和不变性的"业务逻辑"之间进行集成。

如果它们根本没有任何逻辑,它们就是数据传输对象,并且几乎没有用处(DTO实际上只是为了在已知的"形状"中移动数据)。

业务逻辑通常位于"事务脚本"中(通常我们将其实现为IPersonService或IEmployeeService等,使用IEmployeeService.HireNewEmployee(args])等方法,或者,如果您的域对于系统的这一部分来说足够复杂,则为"域模型"。

无论您采用哪种方式,您都会发现这些实现业务逻辑的类将由 ViewModel 调用。

模型可以而且应该包含业务逻辑。ViewModel 不应包含任何业务逻辑,而只包含与视图相关的逻辑。

对于此特定方案,可以在视图模型中添加逻辑。

记住责任——

模型 - 任何作为业务逻辑的逻辑,并且是该特定模型或实体的规则,则该逻辑应放置在模型中。例如 - 如果您有一个名为"引擎"的实体,则运行引擎的实际业务详细说明了气体泵送的速度,所有基本操作都在引擎类中,即模型

视图模型 - 用于执行操作以便在 UI 上显示适当数据的任何逻辑

现在,该引擎的外观应该如何管理UI所需的任何操作,不会影响其工作,并且仅与UI相关,因此这些逻辑和详细信息应放在View Model中。

正如其他答案和评论所显示的那样,这是一个引起很多激情和意见的话题。没有一种"正确"的方法可以做到这一点。

你可以认为模型只是一组DTO/POCO,或者你想怎么称呼它们。然后,您的持久性层和业务逻辑层位于 ViewModel 中。

您可以认为模型是一个持久性层,只负责持久化 DTO,并且业务逻辑位于 ViewModel 中。

您可以认为 ViewModel 只负责处理视图逻辑(应用行为),并且模型中存在业务逻辑和持久性。

你可以采取的立场...等等。您可以采用贫血数据模型方法;或丰富的数据模型方法等。

没有一种正确的方法来解决这个问题。失去了同样有效的方法。所有方法的两个关键点是:

  1. 决定一种方法并坚持下去。在整个解决方案中保持一致。
  2. 确保层正确解耦,无论采用何种方法。

通常,验证同时在 ViewModels 和 Model 上完成。ViewModels倾向于注意与业务相关的逻辑,而模型的验证纯粹用于确保其数据有意义。例如,应在Person模型上验证gender属性。这是因为这是一个事实,性别只能是malefemale,无论商业逻辑是什么。