When using a domain model, you constuct an object graph at runtime instead of using DataTables. Objects in this object graph are business objects (also called domain entities). For example, the customer object contains references to orders which contain references to OrderDetails. Collections of these domain entities are stored in ArrayLists or other types of object collections at runtime; nowhere do you see any references to DataSets or DataTables.

The Fowler book "Patterns of Enterprise Application Architecture" is really good at explaining the different approaches to data access. http://www.martinfowler.com/eaaCatalog/domainModel.html

"Domain Driven Design" by Eric Evans is a masterpiece. http://www.domaindrivendesign.org/book/index.html

This series of articles is pretty good: http://www.devx.com/vb2themax/Article/19892


>David,
>
>PMFJI,
>Do you know of a white paper, web site, or a book that explains what you refers to as "domain model" business object? I am completely ignorant on the subject but would like to learn.
>
>Thank you.
>
>>Vlad,
>>
>>Why don't you want to use a domain model? Is the business logic really so simple? Have you taken a look at ObjectSpaces?
>>
>>>Hi all,
>>>
>>>Does anybody know a .net sample application that is using typed datasets to gor business objects/data access objects?
>>>I am trying to move away from the classic domain model and take advantage of the ado.net features.
>>>
>>>Thanks ,
>>>
>>>Vlad