如何处理与多个集合根视图模型？ [英] How to handle view model with multiple aggregate roots?

问题描述

目前，我得到了相当严重的老式浏览模式。

At the moment, i got quite badly fashioned view model.

类看起来像这样=>

 public class AccountActionsForm
    {
        public Reader Reader { get; set; }
        //something...
    }

问题是，阅读器类型来自域模型（SRP违规的）。

Problem is that Reader type comes from domain model (violation of SRP).

基本上，我在找设计技巧（即它是一个好主意，拆分视图模式，输入/输出？）如何使我的视图模型摩擦少，开发者友好的（即 - 映射应自动工作使用控制器基类）？

Basically, i'm looking for design tips (i.e. is it a good idea to split view model to inputs/outputs?) how to make my view model friction-less and developer friendly (i.e. - mapping should work automatically using controller base class)?

我知道AutoMapper框架，我有可能会使用它。

I'm aware of AutoMapper framework and i'm likely going to use it.

所以，一旦更多 - 努力创造适当的视图模型时，有哪些常见的问题？如何构建呢？如何时，有必要在多域对象输入映射完成？

So, once more - what are common gotchas when trying to create proper view model? How to structure it? How mapping is done when there's a multiple domain object input necessary?

我感到困惑的情况下，当认为从超过1聚合根需要的数据。我创建的应用程序有像图书馆，读者，BibliographicRecord等。

I'm confused about cases when view needs data from more than 1 aggregate root. I'm creating app which has entities like Library, Reader, BibliographicRecord etc.

在我的情况 - 在域级别，这是没有意义的组所有3种类型的成 LibraryReaderThatHasOrderedSomeBooks 或诸如此类的东西，但认为应约责令书特定显示列表读者在特定的库需要他们。

In my case - at domain level, it makes no sense to group all those 3 types into LibraryReaderThatHasOrderedSomeBooks or whatnot, but view that should display list about ordered books for specific reader in specific library needs them all.

所以 - 它似乎罚款下面持有 OrderedBooksList 与 OrderedBooksListModel 视图模型> LibraryOutput ， ReaderOutput 和 BibliographicRecordOutput 视图模型。甚至更好 - OrderedBooksListModel 视图模型，它利用的压扁技术，并有一个像 ReaderFirstName ，库名称道具等。

So - it seems fine to create view OrderedBooksList with OrderedBooksListModel view model underneath that holds LibraryOutput, ReaderOutput and BibliographicRecordOutput view models. Or even better - OrderedBooksListModel view model, that leverages flattening technique and has props like ReaderFirstName, LibraryName etc.

但是，因为有多个输入，导致映射问题。结果，
这不是1：1的关系了，其中我在一个聚合根只踢结果。
这是否意味着我的域模型是怎样的一个问题？

But that leads to mapping problems because there are more than one input.
It's not 1:1 relation anymore where i kick in one aggregate root only.
Does that mean my domain model is kind a wrong?

和什么有关纯粹生活UI层视图模型领域（即枚举，表示检查选项卡）？

And what about view model fields that live purely on UI layer (i.e. enum that indicates checked tab)?

是<一个href=\"http://stackoverflow.com/questions/944334/asp-net-mvc-view-with-multiple-models/944371#944371\">this在这样的情况下，每个人都呢？

Is this what everyone does in such a cases?

 FooBarViewData fbvd = new FooBarViewData();
   fbvd.Foo = new Foo(){ A = "aaa"};
   fbvd.Bar = new Bar(){ B = "bbb"};
   return View(fbvd);

我不愿意这样做=>

I'm not willing to do this=>

var fbvd = new FooBarViewData();
   fbvd.FooOutput =  _mapper.Map<Foo,FooOutput>(new Foo(){ A = "aaa"});
   fbvd.BarOutput = _mapper.Map<Bar,BarOutput>(new Bar(){ B = "bbb"});
   return View(fbvd);

好像很多写作。 ：）

Seems like a lot of writing. :)

<一个href=\"http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/06/29/how-we-do-mvc-view-models.aspx\"相对=nofollow>读这的时刻。和<一个href=\"http://$c$cbetter.com/blogs/jeremy.miller/archive/2008/10/23/our-opinions-on-the-asp-net-mvc-introducing-the-thunderdome-principle.aspx\"相对=nofollow>这个。

确定。我想过这个问题了很多，是的 - 增加一个抽象层似乎是一个解决方案=>

Ok. I thought about this issue a lot and yeah - adding another abstraction layer seems like a solution =>

所以 - 在我的脑海这个已经工作的，现在是时候对一些玩弄。

So - in my mind this already works, now it's time for some toying.

TY吉米

推荐答案

这很难界定这一切，但在这里不用。我们喜欢分离出我们称之为什么查看从控制器建立什么看。该观点认为，扁平，脑死亡DTO状物体。我们称这个视图模型。

It's tough to define all these, but here goes. We like to separate out what we call what the View sees from what the Controller builds. The View sees a flattened, brain-dead DTO-like object. We call this a View Model.

在控制器方面，我们建立的构建视图模型所需要的丰富的图表。这可能只是一个单一的聚合根，也可以是几个聚合根的组合物。所有这些结合在一起为我们称之为的presentation模型。有时，presentation模型只是我们的持久性（域）型号，但有时它是一个新的对象完全。然而，我们在实践中发现的是，如果我们需要建立复合presentation型号，它往往成为相关行为的磁石。

On the Controller side, we build up a rich graph of what's needed to build the View Model. This could be just a single aggregate root, or it could be a composition of several aggregate roots. All of these together combine into what we call the Presentation Model. Sometimes the Presentation Model is just our Persistence (Domain) Model, but sometimes it's a new object altogether. However, what we've found in practice is that if we need to build a composite Presentation Model, it tends to become a magnet for related behavior.

在你的榜样，我想创建一个ViewFooBarModel和ViewFooBarViewModel（或ViewFooBarModelDto）。然后，我可以谈论ViewFooBarModel在我的控制器，然后依靠映射来拉平我从AutoMapper这中间模型所需要的。

In your example, I'd create a ViewFooBarModel, and a ViewFooBarViewModel (or ViewFooBarModelDto). I can then talk about ViewFooBarModel in my controller, and then rely on mapping to flatten out what I need from this intermediate model with AutoMapper.

这篇关于如何处理与多个集合根视图模型？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！