为什么要创建类来表示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认可该方法背后的原因是什么？我在这里盖好了吗，还是我错过了什么？