Question

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 as employees[i].Name where employees is an IEnumerable<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?

Answer 1

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.

• Example: Need to setup a URLRewrite when a page name changes? One central location for this is clearly ideal.

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.

• With LINQ to SQL, you get the benefits without the drawbacks (that you mentioned), plus a few extra benefits.

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.