StrataFrame has a cool feature they call the Business Object Mapper. This tool helps build and maintain strongly typed properties on the Business Object that represent columns in the associated table or view. It also has features to let me override part or all of the mapping.

Mere Mortals has a Business Object generator that serves a similar purpose, but generates multiple class definitions for the Business Object, Business Entity Object, Business Rule Object, and Default Values Object. You can independently choose to (re)generate any or all of these class definitions each time you run the generator.

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.

With either approach I can add additional “calculated columns” to either create a calculated field such as an extended price (quantity * price) or to translate a type into something more useful, e.g. convert stored integer centi-seconds into a TimeSpan type for display and processing. (There are, however, different limitations on how I can use those properties, as discussed below.)

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.

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.

On the SF side of the ledger, I can easily directly data bind form controls to the BO properties, whereas I have not yet figured out how to directly bind to the Entity object that is part of the MM BO. (I have another thread in the MM category asking about this.) I don’t know how much of that has to do with the way SF does data binding vs. MM and how much has to do with the nature of having properties on the BO vs. properties on a separate Entity object. What this means is that I cannot view or edit my custom Entity columns in simple controls on an MM form.

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.

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. However, both systems’ tools allow for changing the names during generation. (I should note that there are also other problematic names [e.g. keywords] that .Net compilers will barf over.)

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

Any comments?

...Jim