为什么要有两个类,View Model和Domain Model?

12 浏览
0 Comments

为什么要有两个类,View Model和Domain Model?

我知道使用领域模型作为视图模型可能会有问题。如果我的领域模型有一个名为IsAdmin的属性,并且我有一个用于创建用户的Create控制器操作,有人可能会修改我的表单并将其POST为IsAdmin=true的值,即使我在视图中没有公开这样的文本字段。如果我使用模型绑定,那么当我提交我的领域模型时,那个人现在将成为管理员。因此,解决方案是仅公开视图模型中需要的属性,并使用像AutoMapper这样的工具将返回的视图模型对象的属性值映射到领域模型对象的属性值。但是,我读到了类上的绑定属性可以用来指示模型绑定器应该和不应该绑定的属性。那么,为什么要创建两个分开的类(领域模型和视图模型),这两个类本质上表示相同的东西,并且还要额外费时地进行映射呢?这更多是一个代码组织问题吗?如果是这样,我会得到什么好处呢?

编辑

我遇到的最重要的创建视图模型与领域模型分离的原因之一是需要实现MVVM模式(基于Martin Fowler的PM模式)来管理复杂的用户界面。

0
0 Comments

为什么需要视图模型和领域模型两个类?

在开发过程中,我发现尽管我的领域模型在大部分情况下可以满足我对视图的需求,但它并不能完全覆盖我想要在视图上展示的100%的值,特别是当涉及到权限以及用户是否应该对某些视图部分具有访问权限时。

设计理念是尽量减少视图中的逻辑。这意味着在我的视图模型中会有一些字段,比如"CanViewThisField"或"CanEditThisField"。当我刚开始使用MVC时,我的领域模型就是我的视图模型,但我总是遇到这样的情况:我需要增加一个或两个字段来使我的视图更清晰。后来,我开始使用视图模型/模型构建器的方法,这对我来说非常有效。我不再与我的代码作斗争,而是可以根据需要增强我的视图模型,而不会影响领域模型。

我同意让视图更加简洁,但是我们是否可以将这种功能抽象到领域模型中,而不是视图模型中呢?我之前提到过这个问题,我能否在我的领域模型上使用DisplayAddress()函数,将领域属性如Address、City、State和Zip结合起来?数据库只映射属性,而不是函数。

显然,任何事情都是有可能的,取决于你想走哪条路。我的领域模型是由代码自动生成的,所以我不需要直接操作那部分代码。如果你使用任何ORM,则情况也是如此。视图模型对我来说提供了最大的灵活性,而且性能也没有受到影响。

对不起,我直到现在才打开你给的链接。我得出的结论是决定是否采用领域模型-视图模型的方式取决于领域模型的需求。我可以理解我的一些领域模型对象会使用视图模型,而有些则不会(尽管这可能会让某些人困惑-我会再想一想)。无论如何,我已经得到了答案。谢谢大家!

我现在还没有使用ORM,但很快会使用。我知道可以在强类型视图中使用EntityFramework类,但如果这些类会经常被删除,我不知道该如何给它们添加属性?谢谢你的提醒。

如果你需要给自动生成的类添加属性,你可以使用部分类或'buddy classes'。

谢谢!所以我猜,在EF ORM中,'buddy class'将是我的视图模型,而自动生成的实体类将是我的领域模型-似乎我不得不给每个自动生成的实体类都提供一个视图模型,即使只是为了使用一些很酷的验证属性。但我读到AutoMapper在处理大量数据时非常慢,因为它有复杂的映射逻辑。如果你知道有一个更高效的解决方案,请给我提供链接。

0
0 Comments

为什么会出现View Model和Domain Model两个类?出现的原因是为了解决在不同视图下需要展示不同数据的问题。View Model只包含视图所需的成员,可以看作是对底层领域模型的简化或者“扁平化”。

举个例子,假设有一个Order类,其中包含一个名为Customer的成员,它是一个组合关联,也就是说Order“拥有一个”Customer。Customer对象又包含一些成员,比如Firstname和Lastname等。但是,在订单的“详情”视图或者订单列表视图中,如何展示这些信息呢?

通过使用View Model,可以创建一个OrderListItemViewModel类,它包含一个CustomerName成员,可以将Customer对象中的Firstname和Lastname组合起来映射到这个成员上。可以手动完成这个映射,也可以使用AutoMapper或类似的工具来实现。

使用这种方法,可以针对不同的视图创建多个特定的Order View Model,例如,订单列表视图可能以不同的方式展示顾客姓名和订单详情视图。

View Model的另一个优点是可以减少在视图中不需要的底层领域对象的冗余数据。例如,如果我正在查看订单列表,是否真的需要看到所有顾客的联系信息、账单详情等?这取决于列表的目的,但通常来说是不需要的。

因此,View Model和Domain Model两个类的出现,解决了在不同视图下展示不同数据的问题,并且可以简化视图所需的数据,提高了代码的可复用性和可维护性。

0
0 Comments

为什么需要两个类,视图模型和领域模型?

有几个原因可以解释为什么需要两个类,视图模型和领域模型。

首先,视图模型的存在是为了解决数据分页的问题。如果将一个包含多个人的数组(Person[])直接传递给视图,那么一些元数据,比如页数、当前页的编号以及每页的大小等信息,并不属于Person类的属性。因此,PersonListViewModel的出现可以很好地解决这个问题。

其次,视图模型和领域模型有着不同的职责。领域模型是指在应用程序中表示业务逻辑和数据的模型,它主要关注数据的处理和业务规则的应用。而视图模型则是用于展示数据和与用户交互的模型,它主要关注于呈现数据给用户并接收用户的输入。

由于视图模型和领域模型的职责不同,将它们分离开来可以使代码更加清晰和可维护。视图模型可以根据具体的展示需求来设计,而领域模型可以专注于实现业务逻辑。

最后,视图模型还可以提供一种适应不同展示需求的灵活性。不同的视图可能对数据的展示方式有所差异,通过使用视图模型,可以根据具体的展示需求来定制数据的呈现方式,而不需要修改领域模型。

因此,通过使用视图模型和领域模型,我们可以更好地解决数据分页的问题,同时也能使代码更加清晰和可维护,提供灵活性来适应不同的展示需求。

0