As an exercise I implemented the example in the article with a typed dataset. It has a User table with a one-to-many relationship to a role table. This is the code I came up with to create a user and give the user a role of Manager using the dataset. (The numbers are pks. I think I could set up auto incrementing that would eliminate having to pass them in)

Dataset1 ds = new Dataset1();
ds.User.AddUserRow(1,"Dave");
Dataset1.UserRow dave = ds.User[0];
ds.Role.AddRoleRow(999,"Manager",dave);

And here is the code if I were using domain model business objects.

User dave = new User("Dave");
dave.Roles.Add(new Role("Manager"));

Notice that the domain model preserves the semantics of the object oriented language. If I want to create a new object I just use new! If I want to add an object to a collection I just add it. With the typed dataset I have to add a row to "simulate" instantiating a new user. That is confusing and counter intuitive.

That is why I say the dataset is relational and not object oriented. The domain model keeps my logic clean and separated from data access.


>I don't really see why you're so against them.
>