为什么要创建类来表示 Web 应用程序中的数据？
过去，我通常使用类来表示我设计和构建的应用程序中的数据。但在 Web 应用程序中，这似乎不需要/不适用，因为数据存储在数据库中，而像 DataSet 这样的东西非常适合检索和保存数据。
我目前使用 ASP.NET，数据绑定控件（例如 GridView）似乎喜欢绑定到 SqlDataSource、ObjectDataSource、 DataView 等。因此，给定一个从数据库中提取 DataSet 的静态 MyDB 类，我的面向数据的页面代码通常看起来本质上是这样的：像这样：
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 - 在 C# 3 及更高版本中，能够在
IEnumerable上使用 LINQ 和超酷扩展方法来灵活筛选数据集合，而不必创建/更改数据集合对于我需要执行的每个聚合/选择，数据库中的存储过程或查询。 - 与数据库相比，源代码在 SCM 下更容易保存，这意味着在源代码中保留更多逻辑会更好。
- 像我这样学过 CS 的人做本地应用程序会更舒服:-)
另一方面，在将数据显示到屏幕上之前将数据转换为 .NET 类是一个需要计算时间的步骤，而且并不是绝对必要的。我有一种感觉，GridView 及其同胞更喜欢绑定到 DataView，而不是 IEnumerable。此外，数据库在查询和聚合数据方面将比 LINQ 更快。
POCO 认可这种方法背后的理由是什么？我是否已经在这里介绍过它，或者我遗漏了什么？
In the past, I've generally used classes to represent my data in applications I design and build. But in web applications, that doesn't seem to be needed/applicable, because data is stored in a database, and things like DataSet work great for retrieving and saving data.
I currently work with ASP.NET, and the data-bound controls (such as GridView) seem to like to bind to SqlDataSource, ObjectDataSource, DataView, etc. So, given a static MyDB class that pulls a DataSet out of the database, my data-oriented page code often essentially looks like this:
DataSet employeeData = MyDB.GetData();
DataView dvEmpData = new DataView(employeeData);
grdData.DataSource = dvEmpData;
grdData.DataBind();
Thus I don't generally have data classes to correspond to my database schema. But new developments like POCO and the EF Framework endorse creating and using those classes. What is the advantage of this? My ideas are:
- Compile-time errors where misspellings would have otherwise gone unnoticed until runtime.
employeeData[0].Rows[i]["Name"]is not as nice asemployees[i].Namewhereemployeesis anIEnumerable<Employee> - In C# 3 and later, ability to use LINQ and cool extension methods on
IEnumerable<T>to filter data collections flexibly instead of having to create/change a stored procedure or query in the database for every aggregation/selection I need to do. - Source code is easier to keep under SCM than database stuff, which means keeping more logic in the source code is better.
- A guy like me who learned CS doing local applications is more comfortable :-)
On the other hand, converting data to .NET classes before putting them onscreen is a step that will take computational time, and is not strictly necessary. And I've got a feeling that GridView and its compatriots will prefer binding to DataView over IEnumerable<T>. Also, the database is going to be faster at querying and aggregating data than LINQ.
What is the reasoning behind the approach endorsed by POCO? Have I covered it here, or am I missing something?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
简明地回答您的具体问题：
利用业务对象，您可以比在 SQL 中或在多个位置以临时方式更有效地对内存中的数据执行逻辑。
但是...
您可以通过使用 LINQ to SQL 排除大多数负面因素，或者在更复杂的情况下，使用其他 ORM，例如 实体框架 或 nHibernate。
阅读第 1 部分 和 第 2 部分 Scott Gu 的有关 LINQ to SQL 的博客，以获取有关该主题的一些灵感。
但是...
在您不需要这种不平凡的逻辑的情况下 - 您也可以使用 SQLDataSource 并直接绑定到 Gridview；然而，LINQ to SQL 非常简单，以至于许多人甚至在最简单的情况下都喜欢它。
To answer your specific question concisely:
Utilizing business objects allows you to execute logic on data in a memory more efficiently than in SQL or in an ad-hoc fashion in multiple locations.
However...
You can rule out most negatives by using LINQ to SQL or, in more complex cases, other ORM's such as the Entity Framework or nHibernate.
Read Part 1 and Part 2 of Scott Gu's blog on LINQ to SQL for some inspiration on the subject.
And yet...
In situations where you don't need that sort of non-trivial logical -- you may as well use a SQLDataSource and bind directly to a Gridview; however, LINQ to SQL is so simple that many prefer it even in the simplest of cases.