First, I would like to thank Paul Welter for adding XmlComments and an NDoc-generated help file for the WilsonORMapper v18.104.22.168 -- 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.
I've been busy enough that I haven't bothered with the huge downloads yet to get VS 2005 Beta 1 -- afterall I knew I would get it mailed to me soon enough. Finally this morning the yellow DHL truck arrived with my little package, so I eagerly opened it up. All I found inside was a piece of paper that said I would find the installation media enclosed, which I did not -- talk about vaporware. I guess I'll have to find the time to download it now afterall.
Update: Talk about customer service, someone from MS read my blog and is sending a new copy -- without me even asking. :)
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?
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?
Well, I'm back from my vacation -- we had a great time at Discovery Cove with the dolphins, and much more. Now I've got to figure out how to rectify my very low output, without making just wasteful posts. I've been skimming over all the entries about Whidbey, since its mostly all old news to me. I guess that's the downside of getting early sneak peaks, and I wrote my articles back in October for the PDC.
So, is there anything of significance that I can share? Well, first I want to raise my voice and join Jonathan Goodyear (and others) by saying that I too find all these hard-coded directory names for ASP.NET v2.0 very bad. Like Jonathan, I too raised this objection at a private preview a very long long time ago (try October of 2002). I think there are bound to be a few backwards compatibility issues no matter how hard the ASP.NET team tries to avoid them, but this one just looks plain stupid. Yes, it affects me, since I have a Code directory on my site, but its not just me -- it even affects the ASP.NET Forums! This just should NOT be allowed to continue past this beta, so please lets stand up and demand these hard-coded directory names to be configurable.
Finally, I have one more gripe -- this time against many of the so-called "gurus" of our community. I suppose everyone has seen the many articles and posts about all the cool featues of Whidbey -- but have you noticed what's missing in many cases? I don't understand how well-connected authors can write about things like MasterPages and not even acknowledge that its also possible to at least partially (if not mostly) use a version of MasterPages now -- in the v1.* world that most of us still live in. I love to learn about the latest and greatest, just like everyone else, but I also live in the here and now, so while an article on MasterPages in v2.0 very much has a place, doesn't it also demand at least an acknowledgement about the present? This is just one example, there's also lots of articles on ObjectSpaces (which failed to even make it to the beta) that don't even acknowledge ANY of the existing O/R mappers out there for .NET. Again, I've picked these examples since they are close to my heart, but I've seen this "trend" in many many other articles also, and I'm talking about "gurus" that you would think would know better. Don't these people bother to read other people's articles and/or blogs, or listen to others at the conferences and private previews they attend, or even just do a simple Google search? I spent a few years in the academic world (not much granted, but some), so maybe its just my high standards, but I try to always actively seek to give others credit, and I know at least some others do too -- this is standard practice in the old world. Shouldn't this also be expected in the new brave online world too, at the very least when it comes to those that we hold high as "leaders" for our community. Shouldn't we expect our community "leaders" to actually pay attention to the community that they supposedly are highly involved in -- or are "gurus" just lone thinkers that should not be held up to old world standards?
Sorry if I've offended anyone, but I've been thinking this for quite some time, and it feels good to put it out there. I'll try to make the rest of my posts less rant -- and I should have something interesting soon.