I developed a nifty way to do a universal html <-> domain <-> database mapping object, but I'm wondering if the tight-coupling and lack of separation of concerns are worth it. I have a generic dictionary object that is basically a bunch of cross-indexed maps - that is, you can map x number of keys to the same object. Then I would extend the object and in the ctor, define 3 different mapping types - html, internal, sql. I'd then add each "field" programmatically along with its key names. The benefits of this approach: 1) really really easy to store/load from the database, using simple iteration. 2) likewise with loading from form inputs. The drawbacks: 1) the object is very tightly coupled to both presentation and the database. 2) validation can be trickier. 3) have to go through a few extra steps for manipulation. 4) no primitives, everything's an object. This would be in contrast to the way i'm doing things now, which is having a loader class for form input -> domain and sql -> domain, and the domain object is just a bean. Each of these loader classes are then pretty specific and can't be done iteratively. Any change to the object (like adding/removing fields) must then be taken care of in at least 4 different areas. Sigh, maybe I should just try that new O/R package Hibernate.
It does seem to be tightly coupled. I'm also wary of a Map being the source for the mappings to the other representations of the data. I've done this before, and there nothing maintaining the integrity of the data in the Map. ie the Map begins to be treated like an Object with public attributes - you manipulate the data directly to the Map just as you can directly get and set data without using getter/setters. Personally I like Castor. You have a preferred representation on your data then provide adaptors for it. In Castor it is Object-centric, you map objects to XML and objects to SQL, but it could also be XML-centric. Well, that's my take on it, anyway.