1

我将 C# MVC 与 Razor 一起使用。

假设我有一个显示列表、下拉列表和 2 个文本框的视图。是否应该将所有这些信息保存在 1 类中，然后将其传递给我的视图？

4

5 回答 5

1

使用 ViewModel 将数据从控制器传递到视图的重要性怎么强调也不为过。如您的问题所述，您已经这样做了，这是一个很好的开始！

所以..这就是我会做的。

public class IndexViewModel // or DetailsViewModel or whatever the Action Method is
{
    public IEnumerable<Foo> Foos { get; set; }
    public SelectList DropDownBox { get; set; }
    public string Name { get; set; } // Textbox 1
    public string Description { get; set; } // Textbox 2
}

好的。所以让我们看看我做了什么。

我已经通过了所有View需要的信息。不多也不少。只是-确切-信息。

Foos是一个列表，然后foo您可以循环进行渲染。（专业提示：使用 DisplayTemplates 呈现您的自定义类型/自定义类型的集合）。

我还建议传入一个SelectList下拉内容等。有些人不喜欢这个（这很好）。相反，他们传递了他们的项目集合以在下拉列表中呈现，但我个人认为这太过分了。我们拥有的关键原因ViewModels是我们可以测试这些东西。

最后，每个文本框都有一个属性。

因此，总而言之，我将所有信息放在一个ViewModel. 此视图模型可以包含其他类（通过属性公开）。但是，是的 -每个视图都需要一个 ViewModel。

于 2012-07-06T22:39:11.203 回答
0

从我所做的项目来看，我建议将所有信息保存在一个类中，但这一切都取决于您正在使用的 Idan Arye 所说的数据。根据您的要求，我建议您查看 msdn，这是 C# 的绝佳资源。希望这有帮助

于 2012-07-06T22:23:31.650 回答
0

这取决于您的模型有多大，但是是的，您可以将它们归为一类

例如，如果像 Employee 和 3 一样简单，如下所示，则将其保留在 1 类中。但是，如果它比这个大 3 -4 倍并且有更复杂的数据字段，那么请尝试将它们保存在单独的类中

public class EmployeeController : Controller
{
    public ActionResult Index()
    {
       var employeeModel = new Employee
       {
           FirstName = "Hat",
           LastName = "Soft",
           Departments = new BindingList<SelectListItem>
            {
                new SelectListItem {Text = "Accounts", Value = "1"},
                new SelectListItem {Text = "Human Resource", Value = "2"},
                new SelectListItem {Text = "Operations", Value = "3"}
            }
       };

        return View(employeeModel);
    }
}
于 2012-07-06T22:27:49.670 回答
0

也许您真正要问的是我应该使用视图模型吗？

类似于...我应该只为两个对象使用视图模型吗？

恕我直言，视图模型通常非常适合使用 MVC 和 Razor。

Ultimately it is up to you and the decision really depends on your model among other factors. For instance If the bits required for your view are ultimately sourced from different entities in your model then one might argue the answer is yes and you should consider using view models because a single view model can be tailored to suit your view.

Basically view models can help keep your views clean. The main implication to usually consider is the inevitable mapping logic that is required for mapping domain entities to view models and the other way around (e.g. During a GET or POST). AutoMapper is an example of a library you could use to cut down on the mapping code. In my experience it can work well as long as your mapping logic isn't terribly complicated.

于 2012-07-06T22:47:22.557 回答
0

In my opinion, depends what the page is for, if you are to show the properties of a domain object in which case you should consider have a special object for the view (e.g. View Model) your class would the domain's object class (e.g. User) and at some point your View Model's (e.g. UserViewModel).

You can also of course, make use of Value Objects / DTO for carrying compound objects, thus, you'll have to create the correspondent classes that are not domain specific but still needed to transport data across your system, from the DAL to your views.

At the end you'll always need a View Model Class, which would correspond to domain object or a custom DTO / Value Object to present your data in the view.

Hope this helps a bit.

于 2012-07-06T22:48:36.627 回答