Marco lists the following as a disadvantage of typed datasets in Chapter 3 (pg. 55)

“...the thing that .NET developers lament the most is the fact that you can’t easily add your custom buisness and validation logic to a DataSet…”

My question is.. Can’t you do this with partial classes like explained in the following article:

http://www.theserverside.net/tt/arti...ataSetDesigner

Going Beyond the Designer
What if you want to use a data reader to populate a custom business entity instead of populating a data table? What if you want to execute some custom validation of a column value when it is changed by client code? Do these requirements mean you need to abandon the typed data set designer? Not necessarily. These things cannot be set up directly in the designer, but are fairly straightforward to add through partial class extensions. If you add a class to your data access layer project, and put the following code in it:
using System;
using System.ComponentModel;
using System.Data.SqlClient;
using System.Data;

namespace NorthwindDataAccess.EmployeesDataSetTableAdapters
{
   public partial class EmployeesTableAdapter : Component
   {
      public SqlDataReader GetReader()
      {
         return Adapter.SelectCommand.ExecuteReader(
            CommandBehavior.CloseConnection);

That's a great article, and one of my favorite sites. I have this debate with developers in my community on a regular basis, and there's no such thing as a right answer - that's why we enjoy the debate. If it were a slam-dunk we'd quickly grow tired of the subject.

One of our local experts wrote a book on ADO.NET and he's a strong proponent of leveraging the DataSet in advanced ways. I'm of the other school of thought that says custom is better, unless you have a trivial requirement.

In my mind, people who wrap the DataSet are locking themselves to an object they have no control over, and might change in incompatible ways in the future. You're also locking yourself down to .NET rather strongly, and causing trouble with web services in the future.

Rolling-your-own isn't so hard when you write code generation programs. I like these as addins to Visual Studio. This improves productivity and makes the custom method easier than wrapping DataSets for your regular application programmers.

Choose the option that makes the most sense to you, and the one that lets you sleep best at night. Sleep is a good thing!

Eric

Eric,
thanks for the response!

You say that "people who wrap the DataSet are locking themselves to an object they have no control over".

My question is: Isn't this lack of control possible to overcome with these partial class extensions listed above?

I understand it locks you down to .NET but it does allow all the control you could want.

Chirag

If I don't have the source for an object, then it's not mine. I don't like the idea of injecting new functionality (other than simple inheritance) into objects I don't own, although a lot of people do. You may want to check out Aspect Oriented Programming. This is not my cup of tea, but you might like it.

AOP developers constantly seem to be intercepting and injecting. There's a class of problems where this is the best solution, but whether it should be applied more generally is open for debate.

I don't mind using stock objects that I don't have the source for, but I don't want to inject or wrap my own extensions into an object that wasn't intended to be extended in this manner. I'm not saying it's wrong for you, but it would be wrong for me.

Any further discussion of this topic should take place after injesting a couple adult beverages in an appropriate setting. Some people argue about football on a Saturday afternoon at the pub, but I sit at the table and argue about software design patterns and methodologies - you're right, I need a life :-)

Eric

I'm currently working with .NET 2.0 typed datasets after previously working with Hibernate. Something that I was accustomed to doing in Hibernate, I can't figure out how to do in typed datasets, namely, adding to an association.

For example, given an xsd file named CustomerAggregate.xsd containing a Customer and Invoice classes (and Invoice has a foreign key many-to-one relationship to customer), how do I do this?

SqlTransaction transaction = customerAdapter.BeginTransaction(connection);
customerAdapter.FillByCustomerID(customerAggregate .Customers, customerID);
invoicesAdapter.FillByCustomerID(customerAggregate .Invoices, customerID);
CustomerAggregate.CustomersRow customer = customerAggregate.Customers[0];
InvoicesRow[] invoices = customer.getInvoicesRows();
InvoiceRow invoice = new CustomerAggregate.InvoiceRow(); // NOT ALLOWED--HOW DO I DO THIS LINE??
invoice.Net = 250.00;
invoice.Tax = 27.52;
customerAggregate.Invoices.AddInvoicesRow(invoice) ;
customerAdapter.Update(customerAggregate);
transaction.Commit();

Ah. I found it:

SqlTransaction transaction = customerAdapter.BeginTransaction(connection);
customerAdapter.FillByCustomerID(customerAggregate .Customers, customerID);
invoicesAdapter.FillByCustomerID(customerAggregate .Invoices, customerID);
CustomerAggregate.CustomersRow customer = customerAggregate.Customers[0];
InvoicesRow[] invoices = customer.getInvoicesRows();
customerAggregate.Invoices.NewInvoicesRow();
invoice.Net = 250.00;
invoice.Tax = 27.52;
customerAggregate.Invoices.AddInvoicesRow(invoice) ;
customerAdapter.Update(customerAggregate);
transaction.Commit();

Hi All, i'm a fun os custom entities so today i had a debate at work with one of the .NET system architects leader of my company, I propoused the custom entities instead datasets, exactly as Marco Bellinaso exposes on his book.

After a long discussion I was excommunicated by my boss, he disagrees with custom entities, his main argument saids that there are an extra pay load when the data reader retrives the information from db and then creates the List Of Entity inside a loop, he saids we are waisting a lot of memory and procesing time because we have the information twice in memory 1 in the data reader and then 1 copy in the List Of MyEntity, and there is no reason to use custom entities for web applications.

Is this a good reason to choose datasets instead custom entities? can some on give me more arguments to use custom entities instead datasets:

We have a very large application with many simultaneous users and big databases, this is no t a small application.

Thanks for your comments

This is a totally blanket statement which makes no sense unless you take into account what kind of data you're dealing with, how it's being pulled from the database, and how it's being used.

It is probably true that in most cases, there is a very tiny advantage in performance with typed DS's, but almost always at the expense of flexibility and maintainability. I'm not willing to make that tradeoff, no way.

You can make your custom entities perform fast by using DataReaders, taking advantage of lazy loading, and making heavy use of HttpCache, like TheBeerHouse does.

You can do other things too, like building custom filters and custom comparers for filtering and sorting.

My biggest problem with datasets is that they do not abstract away the details of the database enough for me. Once I'm beyond the DAL and inside the business layer, I do NOT want to be dealing with rows and columns any more, period. I want to be dealing with domain objects and their properties at that point.

I understand that Adapters are supposed to "take care" of this issue, but like Eric said before, I want to be in complete control of my domain objects, thank you very much.

Maybe someone else will chime in at this point and tell me I'm full of s***...

__________________
Visit my blog at http://leedumond.com
Follow me on Twitter: http://twitter.com/LeeDumond