根据 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
没有太多的可能性:
- 视图模型负责
- 可以在模型中实现小段代码
- 检查可以作为 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 模型(如果这很重要)
我认为你这里的课程比你想象的要多。您的 ViewModel 类正在执行与 MVC 中的控制器类似的工作。它们不应该包含任何业务逻辑,但它们应该协调具有业务逻辑的类,即您的应用程序逻辑。
因此,我们有"应用程序逻辑",它控制UI,将数据绑定到视图,并在用户执行的操作/看到的内容与实现其规则和不变性的"业务逻辑"之间进行集成。
如果它们根本没有任何逻辑,它们就是数据传输对象,并且几乎没有用处(DTO实际上只是为了在已知的"形状"中移动数据)。
业务逻辑通常位于"事务脚本"中(通常我们将其实现为IPersonService或IEmployeeService等,使用IEmployeeService.HireNewEmployee(args])
等方法,或者,如果您的域对于系统的这一部分来说足够复杂,则为"域模型"。
无论您采用哪种方式,您都会发现这些实现业务逻辑的类将由 ViewModel 调用。
模型可以而且应该包含业务逻辑。ViewModel 不应包含任何业务逻辑,而只包含与视图相关的逻辑。
对于此特定方案,可以在视图模型中添加逻辑。
记住责任——
模型 - 任何作为业务逻辑的逻辑,并且是该特定模型或实体的规则,则该逻辑应放置在模型中。例如 - 如果您有一个名为"引擎"的实体,则运行引擎的实际业务详细说明了气体泵送的速度,所有基本操作都在引擎类中,即模型
视图模型 - 用于执行操作以便在 UI 上显示适当数据的任何逻辑
现在,该引擎的外观应该如何管理UI所需的任何操作,不会影响其工作,并且仅与UI相关,因此这些逻辑和详细信息应放在View Model中。
正如其他答案和评论所显示的那样,这是一个引起很多激情和意见的话题。没有一种"正确"的方法可以做到这一点。
你可以认为模型只是一组DTO/POCO,或者你想怎么称呼它们。然后,您的持久性层和业务逻辑层位于 ViewModel 中。
您可以认为模型是一个持久性层,只负责持久化 DTO,并且业务逻辑位于 ViewModel 中。
您可以认为 ViewModel 只负责处理视图逻辑(应用行为),并且模型中存在业务逻辑和持久性。
你可以采取的立场...等等。您可以采用贫血数据模型方法;或丰富的数据模型方法等。
没有一种正确的方法来解决这个问题。失去了同样有效的方法。所有方法的两个关键点是:
- 决定一种方法并坚持下去。在整个解决方案中保持一致。
- 确保层正确解耦,无论采用何种方法。
通常,验证同时在 ViewModels 和 Model 上完成。ViewModels倾向于注意与业务相关的逻辑,而模型的验证纯粹用于确保其数据有意义。例如,应在Person
模型上验证gender
属性。这是因为这是一个事实,性别只能是male
或female
,无论商业逻辑是什么。