UI Mappers Making News -- OR Mappers Are Common

Jimmy Nilsson recently hosted a small architecture workshop in Lillehammer that is making the news now.  Oh how I wish I could have went, but alas it was a little too far way and costly for me.  Anyhow, so far I've found two things of interest to me in Mats Helander's posts.  First, they didn't spend much time discussing O/R Mapping because its pretty much a given now!  Its been that way in Java for quite some time, and I do believe its getting there in .NET with your top architects too.  Unfortunately, I don't think any such claim should be really made in .NET just yet, since most typical .NET developers still haven't even heard of O/R Mappers in my opinion.  But it is nice to see that at least among my peers that you don't have to spend time justifying O/R Mappers any more.

The other item of interest to me was the discussion of "UI Mappers" -- apparently both Patrik Löwendahl and Roger Johansson are building their own UI Mappers now (update: Roger is building an O/O Mapper).  Of course, as my readers know, I've had a UI Mapper in beta for some time, and in production at a client, so this really makes me think I need to find the time to finish it up.  :)  By the way, I'm sorry for tooting my own horn, but I'm just thrilled to see them use the term "UI Mapper", especially with the likes of Martin Fowler being present, since I invented the term on this blog 6 months ago (at least to my knowledge) !  Oh well, now I need to find the time to finish it up, adding support for other O/R Mappers and 3rd party controls -- what do my readers think about the concept?

8 Comments

  • I think it's a great concept. I've tried for it off and on the last year, with varying degrees of success.



    I was wondering ... have you looked at Ruby on Rails? It takes a R->O (db schema generating class hierarchy) approach, which I guess isn't as OO-pure, but it's really fast and automatic. ActiveRecord generates the data layer at runtime, and the "scaffolding" portion of ActionPack uses the data layer to automatically generate a CRUD interface for the tables.



    It seems to be really successful ... enough that I'm looking to emulate it in dotnet. I was wondering what your thoughts were on it, though, since as I mentioned a few days ago, WilsonORMapper seems to take a somewhat different approach of having config files listing tables and fields.

  • I am very, very curious on how you've solved the flexibility issue as I see many solutions all claiming the flex. But eventually you have a bunch of code you cannot really get through. Looking forward to your public beta :-)

  • Steve: I haven't seen Ruby on Rails -- I only heard of it for the first time the other day actually.



    Michael: I think my final version will be decently flexible, allowing people to build on my basic platform to better fit their needs. But its also true that it won't be as flexible as doing everything yourself -- but the point is that a UI Mapper should enable you to avoid the same old boring UI code, while enforcing more consistency than any other approach, which should suffice for at least most "admin" type screens, if not more -- you can always do the other screens one-off if necessary.

  • Hi, just wanted to point out that my project is not a object->ui mapper , its an object->object mapper which Mats Helander misunderstood in his blogpost.



    Also, the link on my name points to some company ive never heard of... unless there is another Roger Johansson there also doing a mapping project :P

  • Sorry Roger. The link and the content have been updated.

  • Paul,



    I am not sure what you mean by a UI mapper, but if that is simply a tool for mapping entities to screens. Then I wonder if you will just end up creating screens that are functional but unuseable.



    To be useful I believe that you need to create a process model. So you can map from the data model to the process model and from the process model to the ui.



    About a year ago I got seduced by the false promise of mapping the data model directly to the ui. After a while I realised the screens generated where basically un-usable. Unless you were a geek.



    What do you think?

  • Thanks for your thoughts Alex. I certainly don't think a tool like this will replace every screen, but I do believe that the vast majority of screens in most apps are very basic "admin" type screens -- perfect for a tool (whether it be code gen or a runtime meta-data "UI Mapper") to cut development and maintenance time, while also better enforcing consistency and adding far more flexibility than those basic screens typically have.

  • Paul,



    Yeah, I think you are right about Admin etc.

    I tend to think that if you need 50 screens, 40 or so will probably be admin, so your tool will help a lot with 80% of the screens. Don't you think however that the other 20% are the screens people use most?



    What I think is useful about your stuff is that it allows developers to focus on the VISIBLE code, which they can quite easily explain the costs of, as opposed to the less obvious ADMIN screens which are definitely required but are less likely to be understood by the client.



    I wonder if the answer to that 20% of screens which are process oriented and more visible at the requirements gathering and budgeting phase (which are used 80% of the time) is to create a distinct new model to define the data requirements of processes. Because the most used screens are task/process oriented not data oriented, So once you have a processes model you can then do UI mapping to it.



    Of course Admin screens are a good place to start, and can allow developers to forget about 80% of the screens that take 80% of the time. And focus on the 20% which are critical to the sucess of the project, so that has to be a good thing!



    Good luck, look forward to seeing your UI mapper when you've finished!



    Alex

Comments have been disabled for this content.