More on UIMappers and WilsonORMapper

First, I would like to thank Paul Welter for adding XmlComments and an NDoc-generated help file for the WilsonORMapper v2.2.1.0 -- which now supports filter and sortOrder for child relations.  Now, here's a few other thoughts about UI Mappers, especially in comparison with O/R Mappers:

Why not attributes?  Of course I don't really like using attributes for O/R mappings much either, but there is something fundamentally different about UI mappings that pretty much rule them out.  That difference is that while there may only be one way to persist an entity/business class, there are many valid ways to display that same class -- roles, personalization, localization.  Of course, any UI Mapper should also let you programmatically assign the UI mappings at runtime, since you may want to store your mappings in a database for the ultimate in personalization.

Did you notice that O/R Mappers map class fields, whereas a UI Mapper should map class properties?  An O/R Mapper maps the database fields directly to the underlying business/entity class fields since these values have already been persisted -- they should not be validated yet another time.  On the other hand, a UI Mapper should map the user's entries to business/entity class properties since these values should get processed further for validation or other relevant business logic.  For example, I have a Password property that hides both the passwordHash and passwordSalt fields.

2 Comments

  • Agreed, an attribute based UI mapper doesn't make sense and it ties your biz objects too closely to your UI.



    I notice that O/R mappers map class members, not necessarily fields. They could be fields or properties.

  • I dont think that using attributes would necessarily be a bad thing, it just depends on how tightly coupled you want to have your UI mapping with the business object, and how much of an abstraction you want to create your mappings. The biggest advantage of attributes is that you wouldn't need another designer to make the implementation.



    I have noticed that the new 'DataSources' panel is VS2005 beta seems to do something like this. It allows you to reference a data object and select which type of UI input model you want for the property, which seems like a big time saver. Since I don't have the beta yet I don't know if this works for Web forms yet (hopefully), and how much flexability it has.



    One of the things I've been thinking about is Indigo's 'DataContract' model, specifically the 'SharedContract' model, and how it might apply to UI construction. It may be a dead end, but the mental execise might give one an insight.



    It's also always a currious question on who should be 'InCharge' when designing UI. By 'InCharge" I mean providing the control between the UI and the Data. Should the work flow process be incharge? Should the data object be in charge? Should the model be a hybrid?



    Maybe I should go back and get another look at MS UI Application block. It's at 2.0 - maybe it's a better product.

Comments have been disabled for this content.