The current "classic" business object does not inherit from a DataSet. Instead it uses the Table Module design pattern where the business object wraps a dataset. So what you see now is a DataSet that provides the data and a business object that has the methods that operate on the dataset.

The "New" business object, called an entity, will be what you are looking for. The entity business object will have a persistent property that corresponds to each table field. Thus you will have a Category.Name property that will be persisted to the CategoryName column of the Category table. The mapping between the object's property and the table will be described in an xml file that will be used by a data mapper. This is called the Domain Model design pattern.

You are correct that the domain model/entity approach will be much more object oriented.

http://www.martinfowler.com/eaaCatalog/tableModule.html
http://www.martinfowler.com/eaaCatalog/domainModel.html

>I have been evaluating MM for a couple days now and am having problems understanding the Business Object model and how it related to the data object. It appears that the mmBusinessObject inherits from the dataset, but I can find no way to reference individual column data. For example, if I have a BO called Category, then shouldn't I be able to reference the fields in the table as Category.CategoryID or Category.CategoryName in accordance with Object Oriented patterns?
>
>The examples I have seen so far is to create another dataset using the .GetDataSet method that makes another trip to the database to get the data. Then fields are referenced through the .DataRow("CategoryID") terminology. This does not conform to the OOP pattern and is not strongly typed.
>
>I think I am missing something--can anyone help me out?
>
>Dave