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

如何解决为什么要创建类来表示Web应用程序中的数据？

| 过去，我通常使用类来表示我在设计和构建的应用程序中的数据。但是在Web应用程序中，这似乎不是必需的/不适用的，因为数据存储在数据库中，并且诸如“ 0”之类的东西对于检索和保存数据非常有用。 我目前正在使用ASP.NET，数据绑定控件（例如

GridView

）似乎想绑定到

sqlDataSource

，

ObjectDataSource

，

DataView

等。因此，给定一个静态

MyDB

类，它将

DataSet

从数据库中拉出，面向数据的页面代码通常基本上是这样的：

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

因此，我通常没有对应于数据库模式的数据类。但是POCO和EF Framework之类的新发展支持创建和使用这些类。这有什么好处？我的想法是： 编译时错误，否则拼写错误将在运行时不被注意。

employeeData[0].Rows[i][\"Name\"]

不如

employees[i].Name

好，其中

employees

是

IEnumerable<Employee>

在C＃3和更高版本中，能够在

IEnumerable<T>

上使用LINQ和很酷的扩展方法来灵活地过滤数据集合，而不必为我需要进行的每个聚合/选择创建/更改存储过程或在数据库中查询。 在SCM下，源代码比在数据库中更容易保存，这意味着在源代码中保留更多逻辑会更好。 像我这样学习过CS进行本地应用程序的人比较舒服:-) 另一方面，在将数据显示在屏幕上之前将数据转换为.NET类是一个需要花费大量计算时间的步骤，并非绝对必要。而且我有一种感觉，ѭ1和它的同胞比prefer12更喜欢绑定到ѭ4。而且，数据库在查询和聚合数据方面将比LINQ更快。 POCO认可该方法背后的原因是什么？我在这里盖好了吗，还是我错过了什么？     

解决方法

简要回答您的特定问题： 利用业务对象，您可以比SQL或在多个位置以临时方式更高效地对内存中的数据执行逻辑。 示例：页面名称更改时是否需要设置URLRewrite？一个中央位置显然是理想的。 然而... 您可以通过使用LINQ to SQL来排除大多数负面影响，或者在更复杂的情况下使用其他ORM，例如实体框架或nHibernate。 请阅读Scott Gu \的LINQ to SQL博客的第1部分和第2部分，以获取有关该主题的一些启发。 使用LINQ to SQL，您将获得好处而没有缺点（如前所述），以及一些额外的好处。 但是... 在不需要那种非平凡的逻辑的情况下，您最好使用SQLDataSource并直接绑定到Gridview。但是，LINQ to SQL非常简单，即使在最简单的情况下，许多人还是喜欢它。