UI Mappers: An Introduction

By now you know what an O/R Mapper is if you're reading my blog -- but what about a UI Mapper?  Maybe it would be more correct to call it an O/UI Mapper, for Object / User Interface Mapper, but since I'm the one making up the term (as far as I know) then I'll just call it a UI Mapper.

So what is a UI Mapper?  First, lets briefly review what an O/R Mapper is, so we can compare it.  An O/R Mapper lets you map an entity/business class, along with its fields, to/from a database so that you do not have to write (nor generate) any data retrieval/persistence code/sql at all.  This lets you focus on your business logic, while having the boring CRUD automatically handled, as well as allowing you to seamlessly target multiple databases if you need that flexibility.  All of this is made possible through a set of "mappings", either in xml or through attributes.

OK, so what is a UI Mapper?  A UI Mapper lets you map an entity/business class, along with its properties, to/from a user interface so you do not have to write (nor generate) most of the UI.  I say most, since you will still want to be able to control the basic "template" of your UI, but you should not have to keep creating the same old boring list and edit screens all the time.  This will again let you focus on your business logic, as well as making it possible to target both Web and Windows interfaces, all through yet another set of "mappings", preferably in xml.

So what does a UI Mapper actually do?  It should allow you easily “define” list and edit screens.  List screens should expose sorting, filtering, and paging, as well as things like alignment and formatting.  Edit screens should expose many types of controls, and custom controls, as well as data-types, validation rules, and related entities, along with inserts and read-only views.  I don't think that you will be able to use a UI Mapper for every screen, but most applications have 80-90% of their screens being the same boring list and edit screens that are easy to map.

So what do you think about the possibility of a UI Mapper, especially teamed with an O/R Mapper?  Or maybe you know of one that already exists, since there are some attempts that I have seen.  I've got my own in beta now -- what would you like to see in order to make it truly worthwhile?

14 Comments

  • I wrote a UI mapper in ASP, which generated XSLT (and applied the transform client-side or server-side) (we used SqlXml), and whilst it worked very well, the hardest thing was form layout. PITA.



    Probably easier now that I understand CSS.



    I must admit to thinking that ASP.NET kind of makes it unnecessary in a lot of cases. Building a form/grid isn't too tricky now (as it could be with ASP).

  • <i> I've got my own in beta now -- what would you like to see in order to make it truly worthwhile?</i>



    I'd like to see it work in a production environment. ;)



  • I'd love to see this.

  • I'd like to see it based around the Observer pattern, personally - I've found that using the MVC pattern with the observer pattern works REALLY well..... tho I guess all of these could be used together..... :)

  • I think it is great idea. It's another must have part of truly solid framework(like o/r mapper). The big question is does asp.net 2.0 with ObjectDataSource and Grid/Form View with two-way databindings eliminates this need?

  • Well, I would say that this sounds like a very waterdowned version of XAML. The alternative, what you are trying to achieve is to have two providers for the rendering of the UI file: one for ASP.NET applications and one for Windows Forms.

  • UI Mapper: Meta-data driven, enables personalization and localization, avoid boring data-hookup, ultimate reuse

    ASP.NET Designer: Total control of layout, but requires lots of boring data-hookup code, and little to no reuse

    ASP.NET v2.0: Many enhancements make easier, but not revolutionary changes, so still need code and little reuse

    UIP AB: Concerned with navigation, not layout of individual list/edit screens, same for other workflow engines

    XAML: XAML is like ASP.NET markup for Windows, and still requires boring data-hookup code, and very little reuse

    WebMaestro: Appears to be just another template/skinning system, no list/edit screens, nor any data integration

  • To Phil:



    I got an email from a Phil in Switzerland, but I was not able to reply to the email address -- so maybe you can send me another email address instead.



    Thanks, Paul Wilson

  • The main thing would be performance I think. I can generate list and edit usercontrols very easily using generation. The benefit with using a template generation (shameless plug of CodeSmith) is that I control the implementation and the style of the code.



    I think using a UI Mapper would negatively affect performance, but I am open to the idea I suppose.

  • Me and my team researched O/R UI Mappers for one of our projects and we are now testing a solution from Modularis. Do any of you have experience with this product?

  • Performance -- My initial data suggests that my list is at least no worse than using a datagrid, and probably better actually. Why? The datagrid (and 3rd party ones only get worse) is very very heavy, and creates a heck of a lot of controls. My ASP.NET list is just an html table that is rendered much more efficiently, and my mappings are cached. The edit "control" does perform slightly less, but its a fraction of a second that is insignificant to me, just like any list gain I have is insignificant to me. In other words, there are some tiny performance gains (list) or losses (edit), but they are miniscule when compared with working your database and sending the response to the client, so . . .



    Anyhow, I have nothing against code generation, and heartily recommend CodeSmith for it, if you need complete control, as opposed to additional flexibility driven by meta-data.



    Modularis -- never heard of it, but looks interesting if you are going down the code generation path -- but make sure you look at what it generates and hopefully you will also be able to modify the templates it uses. DeKlarit is also a very good tool if you want to code gen an entire app, but I would personally use CodeSmith if I wanted to code gen since it gives you complete control -- I have used DeKlarit though as an excellent RAD prototyper.

  • I actually wrote something very similar. I had my business classes that implemented a fairly standard intereface. I then added a few attributes that controlled how they were displayed. The attributes could be applied either on the original class or on any class that inherits it. (For my purposes, I usually created a class that inherited my original class, and called it View).



    So for example, my code would look like this:

    public class Data

    {

    // fields

    }



    [Exposed(true)]

    [ExpectRole(Members.Editors]

    public class DataView

    {

    [Validators(NotNull)]

    [ReadOnly(false)]

    public string Field

    {

    //...

    }

    }



    Anyways, I expanded out the library a bit, and I have used it for several clients.

  • I've written both an O/R mapper and UI Mapper using CodeSmith templates. We use it at the company for which I work to generate business objects and simple list/edit views on those objects.



    The UI Mapper is only a decent headstart though. It's not configurable and only emits text boxes for input fields and no validators. It also only targets web forms. It only takes a few minutes to change certain text boxes to drop down lists if needed, and add validation.



    It's definitely something worthwhile creating. An xml-based UI Mapper with all the features that you mentioned would be awsome. I've never looked into a third party option.

  • Thanks for making-up the name "UI mappers". I've been writing "UI mappers" for the last 5 years and my best at naming those was "metadata UI frameworks for database applications" which is way too nerdy.

Comments have been disabled for this content.