问题描述
编辑:我使填充的更好的东西使用ViewModels 从视图中读取数据,称为 valueInjecter . http://valueinjecter.codeplex.com/
它由 http://prodinner.codeplex.com - asp.net MVC示例应用程序
您可以看到在Prodinner中使用ViewModels的最佳方法
使用ViewModel存储映射逻辑不是一个好主意,因为存在重复和违反SRP,但是现在有了Volueinjecter,我拥有干净的ViewModels和Dry Trugh映射代码
那是旧的东西,不要使用它:
我制作了一个视图模式,用于编辑ASP.NET MVC中的内容 当您必须制作一个以编辑实体的表格,并且必须在表格上添加一些下拉词以选择某些值 时,此模式很有用.
public class OrganisationBadViewModel { //paramterless constructor required, cuz we are gonna get an OrganisationViewModel object from the form in the post save method public OrganisationViewModel() : this(new Organisation()) {} public OrganisationViewModel(Organisation o) { Organisation = o; Country = new SelectList(LookupFacade.Country.GetAll(), "ID", "Description", CountryKey); } //that's the Type for whom i create the viewmodel public Organisation Organisation { get; set; } ... }
推荐答案
有几件事困扰着我.
-
术语. ViewModel是这种情况是一个简单的视图数据,该数据填充了,后来由控制器消耗.视图对控制器一无所知,因为ASP.NET MVC基础架构负责选择控制器和适当的操作.控制器处理用户交互.我认为它看起来更像是被动视图,而不是ViewModel(我认为通过ViewModel,您是指模型视图 - 视图模式).
-
细节.填充查看数据的控制器不应该知道如何实现视图的详细信息.但是,CORMISISATIONVIEWMODEL.CONTRY披露了不必要的细节(SelectListItem是纯视图实现细节).从而使控制器取决于视图实现细节.我认为应该更改它以避免它.考虑使用一些将保存一个国家数据的对象.
希望这会有所帮助.
其他推荐答案
这看起来与wrox 专业ASP.NET MVC 书籍中的推荐做法非常相似.第一章可以从上述URL免费获得.
从第100页开始,他们在 ViewData和ViewModels上有一个部分.
当控制器类决定向客户端渲染HTML响应时,它负责明确传递到视图模板呈现响应所需的所有数据.查看模板永远不要执行任何数据检索或应用程序逻辑 - 而应将其限制为仅具有由控制器传递给该模型/数据的渲染代码.
[...]
使用[" ViewModel"]模式时,我们创建了针对我们特定视图方案进行优化的强类型类,并为我们的视图模板所需的动态值/内容揭示属性.然后,我们的控制器类可以填充并将这些视图优化的类传递给我们的视图模板.这可以启用类型安全,编译时间检查和查看模板中的编辑Intellisense.
取自专业ASP.NET MVC 1.0的"第1章"书呆子晚餐",由Rob Connery等人撰写,由Wrox出版".原件可从 http://tinyurl.com/aspnetmvc
其他推荐答案
通常,我认为它看起来不错,通常是为您的域对象创建ViewModels的好主意.
我还没有看过每一行代码,但是引起我注意的一件事是OrganisationViewModel的构造函数.我会使用:
重写它public OrganisationViewModel() : this(new Organisation()) { } public OrganisationViewModel(Organisation o) { Organisation = o; InitCollections(); }
这将删除一些重复的代码,因为您不必在两个构造函数中调用InitCollections().当然,这只是一个小细节,与一般想法无关.
问题描述
EDIT: I made something much better to fill and read data from a view using ViewModels, called it ValueInjecter. http://valueinjecter.codeplex.com/
it is used by http://prodinner.codeplex.com - an ASP.net MVC sample application
you can see the best way of using ViewModels in prodinner
using the ViewModel to store the mapping logic was not such a good idea because there was repetition and SRP violation, but now with the ValueInjecter I have clean ViewModels and dry mapping code
That's the old stuff, don't use it:
I made a ViewModel pattern for editing stuff in asp.net mvc this pattern is useful when you have to make a form for editing an entity and you have to put on the form some drop-downs for the user to choose some values
public class OrganisationBadViewModel { //paramterless constructor required, cuz we are gonna get an OrganisationViewModel object from the form in the post save method public OrganisationViewModel() : this(new Organisation()) {} public OrganisationViewModel(Organisation o) { Organisation = o; Country = new SelectList(LookupFacade.Country.GetAll(), "ID", "Description", CountryKey); } //that's the Type for whom i create the viewmodel public Organisation Organisation { get; set; } ... }
推荐答案
There are couple of things that bother me.
The terminology. ViewModel is this case is a simple view data that is populated and later consumed by controller. View knows nothing about controller as ASP.NET MVC infrastructure is responsible for selecting controllers and appropriate actions. Controller handles user interaction. I think it looks more like Passive View than ViewModel (I assume that by ViewModel you mean Model-View-ViewModel pattern).
The details. The controller that populates view data is not supposed to know the details of how the view is implemented. However OrganisationViewModel.Country discloses unnecessary details (SelectListItem is pure view implementation detail). Thus making controller dependent on view implementation details. I think it should be changed to avoid it. Consider using some object that will hold the data for a country.
Hope this helps.
其他推荐答案
This looks very similar to the recommended practice in the Wrox Professional ASP.NET MVC book, the first chapter of which is available for free from the above URL.
Starting on page 100 they have a section on ViewData and ViewModels.
When a Controller class decides to render an HTML response back to a client, it is responsible for explicitly passing to the view template all of the data needed to render the response. View templates should never perform any data retrieval or application logic – and should instead limit themselves to only have rendering code that is driven off of the model/data passed to it by the controller.
[...]
When using [the "ViewModel"] pattern we create strongly-typed classes that are optimized for our specific view scenarios, and which expose properties for the dynamic values/content needed by our view templates. Our controller classes can then populate and pass these view-optimized classes to our view template to use. This enables type-safety, compile-time checking, and editor intellisense within view templates.
Taken from "Chapter 1 "Nerd Dinner" from Professional ASP.NET MVC 1.0 written by Rob Connery et al published by Wrox". The original is available at http://tinyurl.com/aspnetmvc
其他推荐答案
In general, I think it looks good, and it's usually a good idea to create viewmodels for your domain objects.
I haven't looked at every single line of code, but one thing that caught my attention was the constructors of OrganisationViewModel. I'd rewrite it using:
public OrganisationViewModel() : this(new Organisation()) { } public OrganisationViewModel(Organisation o) { Organisation = o; InitCollections(); }
This removes some duplicate code, as you don't have to call InitCollections() in both constructors. Of course, this is just a minor detail, and has nothing to do with the general idea.