It really depends on what you are accomplishing. One idea is to have the role
membership null until you are actually pulling members of a role. For person,
you can do the same thing with roles, but it is not as critical if one can be
nullable.

You can work with objects that wrap DataSets to avoid some of the
complexity, but that would be slightly different than the suggestions in the
article.

Hope this helps, as I feel I am rambling a bit right now.

Hey Tom,

This is the a pretty old idea. Though in .Net it may be something new.
This is a common J2EE way to do things in the web realm. Things like
Struts and JavaBeans follow this concept of coverting data into objects
or requests into objects for that matter dont think these can only be
used with the database. I use these to ecapsulate form data as well.

I understand your frustration with his example however you must
understand that all of this depends on what your system needs when
thinking about object relationships. I think you need not get hung up
on the example he gives. Just understand the idea of taking the data
from the data set and putting it into more abstracted domain type
objects.

Here is how I do almost all .net web apps.

Codebehind -> service class -> Dal classes

the serveice layer makes calls into the DAL layer and get the dataset
in return. The Service layer then creates the "Entity Objects" from the
datasets. The service then returns this to the code behind and it is
bound to controls there.

The reason I put Entity Objects in quotes is they are not really entity
objects. That is a term that java uses for persistant data. meaining
they are tied to a records in the database. This is not the case with
what he is describing in this artical. I call these "Entity Objects"
ValueHolders.

Thanks for posting this link it was a nice read. I really enjoyed it.

Thanks,
Brette