asp.net - 为什么要创建类来表示 Web 应用程序中的数据？

Question

过去，我通常使用类来表示我设计和构建的应用程序中的数据。但在 Web 应用程序中，这似乎并不需要/不适用，因为数据存储在数据库中，而诸如 DataSet 之类的东西非常适合检索和保存数据。

我目前使用 ASP.NET，数据绑定(bind)控件(例如 GridView)似乎喜欢绑定(bind)到 SqlDataSource , ObjectDataSource , DataView等。因此，给定静态 MyDB拉出 DataSet 的类在数据库之外，我的面向数据的页面代码通常基本上如下所示:

DataSet employeeData = MyDB.GetData();
DataView dvEmpData = new DataView(employeeData);
grdData.DataSource = dvEmpData;
grdData.DataBind();

因此，我通常没有对应于我的数据库模式的数据类。但是像POCO这样的新发展EF 框架支持创建和使用这些类。这样做的好处是什么？我的想法是:

• 编译时错误，否则拼写错误直到运行时才会被注意到。 employeeData[0].Rows[i]["Name"]不如employees[i].Name好其中 employees是一个 IEnumerable<Employee>
• 在 C# 3 及更高版本中，能够在 IEnumerable<T> 上使用 LINQ 和很酷的扩展方法灵活地过滤数据集合，而不必为我需要做的每个聚合/选择创建/更改数据库中的存储过程或查询。
• 在 SCM 下保存源代码比在数据库中保存更容易，这意味着在源代码中保存更多逻辑会更好。
• 像我这样学过 CS 的人做本地应用会更舒服 :-)

另一方面，在将数据显示在屏幕上之前将数据转换为 .NET 类是一个需要计算时间的步骤，并非绝对必要。我有一种感觉 GridView及其同胞会更喜欢绑定(bind)到DataView在 IEnumerable<T> .此外，数据库在查询和聚合数据方面将比 LINQ 更快。

POCO 认可的方法背后的原因是什么？我是否已在此处进行了介绍，还是遗漏了什么？

Answer 1

简明扼要地回答您的具体问题:

利用业务对象，您可以比在 SQL 中或在多个位置以临时方式更有效地对内存中的数据执行逻辑。

• 示例:需要在页面名称更改时设置 URLRewrite 吗？一个中心位置显然是理想的选择。

但是……

您可以使用 LINQ to SQL 排除大多数负面因素，或者在更复杂的情况下，使用其他 ORM，例如 Entity Framework或 nHibernate .

阅读Part 1和 Part 2 Scott Gu 关于 LINQ to SQL 的博客，以获取有关该主题的一些灵感。

• 使用 LINQ to SQL，您可以在没有缺点(您提到的)的情况下获得好处，此外还有一些额外的好处。

然而...

在您不需要那种非平凡逻辑的情况下——您也可以使用 SQLDataSource并直接绑定(bind)到 Gridview；然而，LINQ to SQL 是如此简单，以至于即使在最简单的情况下，许多人也更喜欢它。