Hi Jim

>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.

Certainly true of StrataFrame (SF).

>An advantage of the MM approach is that I can get a strongly typed List of strongly typed Entities that I can then do cool things with like attach to a DataGridView as a data source or can easily loop through with a for each loop. With the SF approach, I cannot create such a list because there is only one set of columns per BO.

In SF, you can easily foreach through the CurrentDataTable property of the BO (this is a reference to the inner DataTable). You can also use a SF BusinessBindingSource. This is analagous to the native .NET2 BindingSource. You simply set the BusinessBindingSource's BusinessObject property to the appropriate business object. Then, in the grid, you set its DataSource property to the BusinessBindingSource which it sees as a legitimate datasource. Job done :)

>On the SF side of the ledger, I can easily directly data bind form controls to the BO properties

Control binding in SF is a snap - it is really easy.

>On the MM side, I can browse a list of Entity objects, but I have not found a way to browse an SF BO. This means that I cannot browse my SF BO defined custom columns.

Not sure what you mean by "browse" in this context. You can easily use many of the SF BO methods to move through the SF BO. This changes the "CurrentRow" property which subsequently updates the current set of strongly typed properties and any custom properties you may have added to the BO.

>Another observation is that there are far more property names already in use in the SF BO base than in the MM Entity base, so there is a slightly greater likelihood of a column name conflicting with a property name in SF than MM.

I have never ever come across this as an issue.

>One question here, however, is whether or not it is a ”good practice” for SF to generate its own *.Designer.cs (or .vb) classes. I expect it is OK, but don’t know.

It is most definately OK for SF to generate its own Designer.cs layers or any partial class for that matter. Partial classes are very cool and are designed for just this type of situation. If you have a class provided by a third party and it is defined as a partial class, in any situation, you can extend that class to give you additional flexibility, without having to touch the base behaviour and worry over whether regeneration of the class will over-write your custom code. In the words of English comedian, Frankie Howerd ... "Worry Ye Not" :)

HTH