OK, I can see where the domain model might be a little "cleaner" in the example you've shown. But, let's assume that you don't have to pass in a PK when using the Typed DataSet. We can clean up that code a bit more:

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

Yeah, ok, we're still having to mess with adding a row instead of just using "new" to add a new user. But, won't it get more complicated if you're having to add several users? You'll have lots of instantiated user classes. Whereas, with the Typed DataSet methodology, you'll still only have one DataSet, you just add multiple rows.

>The domain model keeps my logic clean and separated from data access.<

A DataSet has nothing to do with DataAccess. And anyway, the biz logic does not need to know anything about where the data comes from ... that can all be in the data access layer.

Anyway, this has been a good discussion, Dave ... thanks. Food for thought for all the lurkers out there. <g>

~~Bonnie



>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.
>>