UI Mappers: A Common Scenario
The best way to understand what I mean by a UI Mapper is to look at a common scenario -- let's say you have to add a new business entity to your new or existing application. What do you have to do to support this new entity? Data, business logic, and UI screens. If you use an O/R Mapper then you will only need to create your mappings for the data, otherwise you will need to create your sql or stored procs, and hook it all to your DAL. As for business logic, some people "skip" this and use datasets, but lets get to the UI.
You'll almost always need to provide a list/grid to view all of your entity instances, as well as provide a screen to create a new instance and to edit any existing instance. A basic list is easy in ASP.NET -- just drop a grid and bind it to your entity/dataset. But what happens when you want to not display some columns, or change the alignment or format of some columns, and how much code do you have to write for sorting and paging? How easy is it to enforce a consistent layout across all of your various list screens, or is it possible to define the alignment and formatting of a column in just one place? Do you have to create separate screens for different roles or locales that require yet another version of your list -- and do you even have the possibility for personalization?
That's beginning to not be so easy afterall, and that was just the simple list screen. What about the edit screen -- it requires the designer to place lots of edit controls, add validator controls, load the data into the controls, and then save the user entries. This may not be hard, but its very repetitive, and there is little to no reuse at all! That's right -- its not easy at all to enforce a consistent layout across edit screens, and any reuse of an edit control with specific properties requires a whole user control. And what about a read-only view, or a different view for specific roles or locales again? None of this is really very "hard", but its very repetitive in even the simplest of cases, and it can become a maintenance nightmare when you need personalization and localization.
A UI Mapper approach lets you simply define the meta-data for these list/edit screens. Yes, you will lose the "control" over every minute detail of your layout you have now, but in most cases that total "control" is what makes it so hard to get any consistency. Yes, ASP.NET v2.0 will make some of it easier, but most of the issues will still remain. And we haven't even looked at the scenario where you need both Web and WinForm clients. So what features does a UI Mapper need in order to make this something you would consider?