我目前正在将一些小型个人网站从 WebForms 转换为 MVC。对于现有站点，数据库架构是可靠的，但我从未真正花时间构建适当的数据/业务模型/层。 aspx 页面都使用各种视图和存储过程直接与数据库对话，这些视图和存储过程是为方便起见而根据需要创建的。使用 MVC，我现在正尝试按照他们所说的“做正确的事”，并使用 LINQ to SQL 和/或实体框架之类的东西来为应用程序构建一个或多个适当的数据模型。
我的问题围绕着构建数据模型的目标。我阅读了各种与模式相关的文章，我意识到最终答案可能取决于我的数据的特征。但通常我是否应该尝试构建包含尽可能多的数据库的更大模型，以便只有一种方法可以与给定的一组表进行交互？还是应该为每个 MVC 视图构建更小的自定义模型，只包含视图需要的数据和访问权限？
【问题讨论】：
标签： asp.net-mvc database data-modeling
或者我应该为每个 MVC 视图构建更小的自定义模型，只包含视图需要的数据和访问权限？
这可能会更好。
不要忘记，您可以将模型固定在层次结构中，因此每个模型中都可以存在 ID、名称、偏好等通用属性。
胖扩展模型可能更适合企业应用程序，其中框架会根据预加载的用户偏好、用户角色、访问权限等自动执行大量操作。对于小型个人项目，尝试保持模型小而可能会更好干净的。这也是一种保护。通过不将不必要的数据放入模型中，您可以确保您的视图不会错误地显示错误的条目，或者提交表单不会错误地覆盖其他一些数据。
【讨论】：
我会选择代表您当前系统中实际数据逻辑的模型，并让您的控制器返回视图需要的模型片段，例如：
控制器：
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 类型函数，我强烈推荐这些。
【讨论】：
通常，您将拥有一个用于数据库的综合领域模型。您可以在服务层或控制器中使用（修改/添加/删除/等）域模型，如果它是一个小应用程序。
但是，对于您的视图，您可以使用演示对象使视图更易于维护。这些有时也称为 DTO 或视图模型对象。基本上，您所做的是创建一个对象，该对象包含模型中填充视图所需的所有数据。
例如：
您的模型可能包括：
public class Car()
{
public string Model;
}
public class Driver()
{
public string Name;
}
您希望视图输出汽车的名称和型号，并且您必须将 Car 和 Driver 模型对象都传递给视图。
您可以创建一个仅包含您需要的数据的对象，而不是将两个模型对象直接从控制器发送到视图：
public class CarAndDriverViewModel()
{
public string CarMake;
public string DriverName;
}
您将从域数据中填充此对象并将其传递给视图。视图将是：
model.DriverName + ": " + model.CarMake
现在您不必担心延迟加载问题或复杂的视图逻辑来处理模型特性。创建这些视图模型对象需要更多的工作，但它们确实有助于保持视图清洁，并提供了一种在将数据发送到视图之前进行格式化的简单方法。
如果您想研究它们，您可以使用一些项目和约定来帮助自动创建视图模型。 AutoMapper 就是一个例子。
【讨论】：