On a personal note, it is unfortunate because I think your new techniques will be more attractive to my Client! Even though it may not be the best way to work, they will find it easier to understand, being closer to what they used to do. So even though I might prefer O-R Mapping, I don't think they will.
I think O/R Mapping at the first sight looks a doom. But when I closer see it. It is the same stuff we do when we write modular Database Actions. The database.xml is a real O/R mapping without Beans.
Ok, let me tell you something. I've done consulting for a company that relies rather havily on AS/400 machines. For those of you that don't know it, AS/400 is soooooo relational-oriented that even the filesystem is bunch of tables.
They rely on SQL so much thay have SQL-wizards in house that program in RPG (think about a horrible programming language... mix it with cobol... stir... not even close!) as you and I speak. Ah, note that AS/400 has a 8.3 char limitation on variable names, so you have wonderful things like
select ASNAMEW, AWCHORD from FOCLI2
In short, their business logic is RPG+SQL, *that* kind of SQL. After seven years (and millions of euros) of producing their own patches on top of a commercial ERP, and several people hired to match that technological needs, they have no OO in-house programmer, nor they want it.
The problem is they have to connect that data (and the business logic that is connected to it) on their intranet.
As weird as it might seem, any O/R tool will drive them nuts for two reasons:
1) none of them think in terms of objects
2) there is no E/R model of their database!
3) only a few people know enough of that database to really extract something meaningful.
Ok, first answer to their problem is: you are hopeless and walk away.
Second answer (that would make me look nicer and them call me again) would be something like Chris' solution.
This example is to shows you a few things:
1) there is no clear-cut solution to every problem. Elegance is never an absolute metric.
2) on the other hand, SoC *IS* an absolute metric, only that concern analysis must be performed on an 'ad-hoc' basis: it can't be done once for every potential problem space.
This said, O/R mapping is *ONE* of the ways to solve the problem of connecting flow logic with business logic and assumes several things:
- objects are easier to deal with than SQL by the people involved in the development process. This is not always true.
- it is possible (in terms of economical feasibility) to perform this mapping and to keep it updated. This is not always true.
- database abstraction and cross-database portability is seen as a value. In most cases, it's not.
- the people are willing to pay the development costs of an additional decoupling layer between their data abstraction and their database representation. In most cases, they aren't.
NOTE: SQL was invented *exactly* to provide that portable abstraction. Today, it's considered nothing different from proprietary language with lots of similarities between products in the same market niche.
The result is that people will use direct SQL mapping much more than any other solution.
They will do it in flow, or in SQLTransformer, or in ESQL, it doesn't matter where, but they will. And we can't do (nor should, if this is a value for them) anything about it.
Now, does this mean that there are no better alternatives? no, I don't think so.
Is O/R the solution? could be.
How would O/R work? so that it is as transparent as possible. This probably rules out Torque-like pre-compilation-based approaches, leading to more dynamically-oriented proxy-based approaches. So OBJ seems more advanced in this context.
Is O/R the solution to every datamapping problem? no way! but it might solve lots of issues with structured-data mapping. AS for unstructure-data mappings, a JSR-170-like repository will hopefully do the job.
But I really don't know, I just want to see people experiment and try things out for a while and for sure there won't be *one* one-size-fits-all solution, but several that will hopefully reduce their overlap to the bare minimum.
-- Stefano Mazzocchi <[EMAIL PROTECTED]> Pluralitas non est ponenda sine necessitate [William of Ockham] --------------------------------------------------------------------
