James,

>Here is another fundamental difference between SF and MM frameworks: SF makes the strongly typed columns properties in the BO definition, while MM creates a separate Entity class based very closely on Object with the columns as properties of the class.

Yes, we chose this approach for both it simplicity (the only properties you see are your custom entity properties) and for performance--You can create a strongly typed list of objects that are very light weight and easily pass between physical application boundaries when necessary. This also makes it far easier to create a base entity class fro which you can derive subclasses. When the properties are on the business object itself you have to subclass the entire business object to get this functionality.

The same goes for business rules. We have these in a separate rules object because it allows you to create base rule classes that can be subclassed and extended. This also allows our business process classes to have their own rules class of the same type as that found on business objects. This takes into account the fact that business rules often do not apply just to a single object. They can span multiple business objects or apply to an entire business process.

>As I understand it (and I’m sureI’ll be corrected if I don’t!), both the SF BO properties and the MM Entity >properties fetch and set their values from/to a data row from the Dataset associated with the BO.

This is true by default, but MM .NET entity objects can also work without an associated DataRow. If a DataRow doesn't exist, then values are get/set from an associated private variable. This allows us to move forward into new technologies such as DLINQ where Microsoft is getting into the Object Relational Mapping business where no DataTables are needed. Our model allows you to work either with a DataTable or without.

>Another cool feature of SF’s tool is that it creates a partial class for its column mappings. So when I modify my tables I can rebuild the properties without loosing the any modifications (e.g. custom column properties) that I have made. I can’t do that with MM’s Entity since it generates the whole class. (I expect it might be easy for Kevin to fix that, however and workarounds exist.)

Actually, the Entity class generated by MM .NET already is partial so you can create another source code file with your own custom properties and you're good to go!

Best Regards,