>I'm trying to model my business objects using Mere Mortals and I have a design question. I have a parent/child relationship between two tables, where the parent table contains just a key and a description of the "type" of the defferent child tables - "person", for example. I had considered having an "entity" business object, and a "person" business object which inherited from entity. My question is, how could this be implemented using MM? It seems like a reasonable desing pattern - would this not be considered a good technique?
>

In typical parlance, an entity has a unique identity. So an entity would be an individual row of your table with a unique primary key value. In MM.NET, business objects can contain a table with several rows (a collection) or a single row (an entity) depending on if you run the GetOrdersByCustomer() method or GetOrderByOrderID() method, for example.

So you would have a Person business object that inherits from ABusinessObject and a PersonTypes business object that inherits from ABusinessObject. The ABusinessObject class would be your common application class for all your business objects.

>The problem I'm facing is this: because business objects in MM have their own defined table and primary key, it's a problem trying to inherit one business object from another, where each business object must deal with it's own table. For example, if I create business object "A" which deals table "TableA", and then inherit from "A" to create "B", where "B" deals with "TableB", the TableName property will remain "A" unless I change it to "B". That is, I need "A" to continue to deal with "TableA", and "B" deals with "TableB". Perhaps an inheritance model is not appropriate for this kind of relationship...
>

Typically you would have a simple one-to-one mapping between your business objects and tables. At my work, we ususally reserve subclassing to override behavior for the different clients. So if maybe client X calculates tax differently, we would subclass the Tax Business object for client x. The name of the table would not change. There may be extra fields in that table for a specific client and the methods of the subclass deal with those extra fields. You CAN change TableName in the subclass, but that is assuming that TableA and TableB have almost the same structure so maybe there is problem with normalization in your database table.

>I'd be interested in hearing suggestions about different design patterns for related business objects.

In general you are talking about how to map objects to data. Get more information here: http://www.agiledata.org/essays/mappingObjects.html spcifically "Mapping inheritance structures"

When using MM.NET I would recommend you create one business object per concrete table. MM.NET is an example of a Table driven architecture. Other approaches are the simplistic Transaction Script or the more complex Domain Model. See http://www.martinfowler.com/eaaCatalog/