Question

我目前正在将一些小型个人网站从WebForms转换为MVC。使用现有站点，数据库架构是可靠的，但我从未真正花时间构建适当的数据/业务模型/层。 aspx页面都使用各种视图和存储过程直接与数据库通信，这些视图和存储过程是为方便起见而创建的。对于MVC，我现在正试图“按照他们的说法做”并使用LINQ to SQL和/或Entity Framework等东西为应用程序构建适当的数据模型。

我的问题围绕着我应该建立数据模型的目标。我已经阅读了各种与模式相关的文章，我意识到最终答案很可能取决于我的数据的特征。但一般来说，我是否应该尝试构建包含尽可能多的数据库的更大模型，以便只有一种方法可以与给定的一组表进行交互？或者我应该为每个仅包含View所需的数据和访问权限的MVC视图构建较小的自定义模型吗？

Answer 1

或者我应该为每个仅包含View所需的数据和访问权限的MVC视图构建较小的自定义模型吗？

这可能会更好。

不要忘记，您可以将模型粘贴在层次结构中，因此每个模型中都可以显示常见属性，如ID，名称，首选项。

胖扩展模型可能更适合企业应用程序，其中框架根据预加载的用户首选项，用户角色，访问权限等自动执行大量操作。对于小型个人项目，可能更好地尝试保持模型小清洁。它也是一种保护。通过不将不必要的数据放入模型中，您可以确保您的视图不会错误地显示错误的条目，或者提交表单不会错误地覆盖其他一些数据。

Answer 2

我会选择代表当前系统中实际数据逻辑的模型，让控制器返回视图所需的模型片段，如：

控制器：

public ActionResult index()
{
    var ListOfObjects = DataHelper.GetAll();
    ViewData.Add(ListOfObjects);
    return View();
}

public ActionResult ViewObject(int id)
{
    var Object= DataHelper.GetObject();
    ViewData.Add(Object);
    return View();
}

public ActionResult ViewObjectChild(int Objectid, int ChildId)
{
    var Child= DataHelper.GetChildObject(Objectid, ChildId);
    ViewData.Add(Child);
    return View();
}

在视图

上

/

<%  var myListOfObjects = ViewData.Get<IList<Object>>(); %>

/的ViewObject / 1 /

<%  var myobject= ViewData.Get<Object>(); %>

/ ViewChild / 1/1 /

<%  var myChild = ViewData.Get<Child>(); %>

注意我已经使用了MVC Contrib类型的函数，我强烈推荐这些函数。

Answer 3

通常，您将拥有一个针对数据库的综合域模型。您可以在服务层或控制器中使用（修改/添加/删除/等）域模型（如果它是一个小应用程序）。

但是，对于您的视图，您可以使用表示对象来使视图更易于维护。这些有时也称为DTO或视图模型对象。基本上，您所做的是创建一个对象，该对象包含模型中填充视图所需的所有数据。

例如：

您的模型可能包括：

public class Car() 
{
  public string Model;
}

public class Driver()
{
  public string Name;
}

您希望视图输出汽车的名称和型号，您必须同时传递汽车和驾驶员模型对象的视图。

您可以创建一个仅包含所需数据的对象，而不是将两个模型对象直接从控制器发送到视图：

public class CarAndDriverViewModel()
{
  public string CarMake;
  public string DriverName;
}

您将从域数据填充此对象并将其传递给视图。观点将是：

model.DriverName + ": " + model.CarMake

现在您不必担心延迟加载问题或复杂的视图逻辑来处理模型特性。创建这些视图模型对象的工作量更大，但它们确实有助于保持视图干净，并且在将数据发送到视图之前提供了一种简单的格式化方法。

如果要查看视图模型，可以使用一些项目和约定来帮助自动创建视图模型。 AutoMapper就是一个例子。

ASP.NET MVC的模型设计建议

3 个答案: