On 9/18/01 11:43 AM, "Fedor Karpelevitch" <[EMAIL PROTECTED]>
wrote:
>>
>> Ambler's design for a persistence layer is very well
>> thought out. It does on the back end what the MVC
>> pattern does on the front end. Where MVC lets the
>> designers and programmers work independently, Ambler's
>> design for a persistence layer lets programmers and
>> DBAs work independently. Another way to put it...
>> it allows the database design to vary independently
>> from the object model.
>
> This sounds cool... on one hand.
> On the other - why is it that useful? It might have been cool if you bought
> your relational model in one place, got the object model in the other and
> then your boss told you that you have to stick them together. Such a tool
> would be really helpful. So would be duct tape. But really, how often is
> this the case?
This is always the case when a piece of software is usecase driven and
modeled by a domain expert and not a programmer. Often times with relatively
small software projects, and I would consider even something like Scarab and
Tambora as small, the data model is designed by the same people who design
the object model. In most cases the object model is nothing more than a thin
veneer over the data model. This is what peers promote with query
construction based on SQL and objects that map to tables. If you are
starting from scratch and have full control over the storage of data than
you are probably all right. For all the jobs that I have walked into that
had been designed by a domain expert (a sensory scientist at Coca Cola for
example), or where the data required to construct an application object
comes from disparate sources (bookstore chain that had in data in a db, xml
store, and flat files) than torque/peers fall 100% short of what's required.
For almost all existing large business whose projects are always large in
scope cannot afford to convert all their data into a single source. They
have many legacy apps that use the data stored wherever it is and it is too
expensive and time consuming to convert or synching issues between the data
stores gets too complicated if it was converted.
In these cases it is absolutely critical that the application object model
be separated from the data model because often times you have to consider an
amalgum of data models. These are real life situations and the ones who have
to deal with most of the time of large projects where the luxury of starting
from scratch or redesigning the system is prohibitively expensive and just
doesn't make sense. The idea of the data dictionary where the info is mapped
from its sources to application objects. It oftens makes more sense to have
a few people know this dictionary than trying to have all the application
progrommers and data modellers know how everything flows. In fact it would
probably be impossible or require so much training that the project would
probably run aground.
In the case of a domain expert the application will usually have zero idea
of how the data is being stored. The application is designed with the
usability of the target audience in mind. Once the application model is
handed over to a software project team it is usually the case that the
application model does not map directly to the data model(s). Pretty much
never in my experience.
In Martin Fowler's Analysis Patterns he states that the best pieces of
software are usually designed by domain experts and whether they have any
computer experience or not has little or no impact on what results. He says
the best application/domain modeler he knows is a doctor in the UK that has
little or no computer experience.
Any sort of persistence layer should handle the simple case where you have
the object model being the data model with some veneer and the real life
cases where you have no option other than to assemble the data into objects
from the sources that exist.
> Unless your really unfortunate, your object model goes hand
> in hand with relational model because ultimately they are just different
> reflections of the same thing.
I totally 100% disagree, in my personal experience I have not found this to
be true. The only people who say this are programmers who are responsible
for both the data model and object model. I also believe this will
inevitibly lead to maintenance nightmares. If the people working on your
project are familiar with both the data model and the object model than
that's great, you're lucky. But this isn't always the case and it's
dangerous for a project that may grow to consider the object model a meager
extension of the data model.
> And all you are buying is that you have to
> design and develop them both separately while making sure they are in sync.
That is always the case on larger projects as stated above. This fact is
accommodated in Ambler's model with the data dictionary. Again if you know
both the data model and the object model that's a boon but shouldn't be a
requirement.
>
>>
>> It would do an excellent job of meeting one of
>> Fedor's goals: let the query model be good java code
>> (as opposed to my goal of making it resemble SQL).
>> Some of that discussion can be found here:
>> http://www.mail-archive.com/[email protected]/msg
>> 00347.html
>>
>>
>> In contrast, Fedor gave some arguments in an unrelated
>> thread against what he found in Castor's persistence
>> layer (which is also modeled on Ambler's design and
>> also trying to be a JDO implementation).
Is it based on Ambler's design? Their JDO implementation is not the same as
Sun's JDO. Just so that's clear.
>> I can't find
>> this note in the archives -- Fedor, maybe you can chime
>> in here. I remember something about Torque being a
>> lighter solution that lets the programmer get to work
>> more easily than the mapping required by Castor.
>
> the subject was something like "Toplink vs. Torque"
>
>>
>> When I first started working with Turbine (around last
>> December) I remember some other discussions about the
>> relative merit of Castor's persistence layer
>> vs. Torque. As I recall, the primary complaint about
>> Castor is that there is a rather complex mapping
>> required between the object model and the data model.
>> That's a rather fundamental component of Ambler's
>> design, and it's exactly what allows the object model
>> to vary independently from the data model.
>>
>
> I would put it like this: A lot of flexibility for a huge cost with
> questionable benefits.
Again I disagree 100%, the benefits are not questionable at all. The
separation is critical for a large project to succeed. I think most of your
experience lies in the data model realm which is totally fine but I think
you're eclipsing the value of the separation because you might not have seen
the benefits first hand. The tool should accommodate the simple and complex,
but more often things tend to get more complex than simple :-)
>>
>> What are the goals for the new persistence layer?
>>
>> My goal was to create something that closely resembled
>> SQL but with enough abstraction to keep the code
>> independent of database vendors. I think my proposal
>> would be much easier to implement, but it requires
>> developers to be conversant in SQL -- the method calls
>> I have created have roughly a one-to-one relationship
>> with SQL fragments.
>
> I think this is more about implementation details and not really the
> model...
I feel that again there should be a separation and any query for objects in
the application should be made in terms of objects being used in the
application. Having to know what the data model is to make a query in the
application to me is not a maintainable thing. Again you are assuming the
application programmer is conversant with the data model and the query
language associated with that data model.
>>
>> Ambler's goal is to let the object model be designed
>> without being constrained by the mismatch between
>> object and relational models.
>
> I see this constraint as natural and I do not see why we should try to get
> rid of it...
Well we totally disagree, as is usually the case :-) The constraint should
not be visible to every application programmer. There is a mismatch and
there always will be but this mismatch shouldn't be brought into every part
of the application. It can be limited to the mapping system, or data
dictionary as Ambler calls it, so that the impact of changes in the data
model have no affect on application programmers.
>
>> The design is sound, but
>> it includes the need for mapping between objects and
>> tables which seemed unpopular in this crowd last
>> December. If you care about the persistence layer and
>> haven't read the two papers I mentioned earlier, I
>> would suggest you do. I think you'll find his argument
>> persuasive. Even if you aren't persuated, the JDO spec
>> is heavily influenced by the design, and is a proposed
>> final draft. I know that Sun's "standards" don't
>> necessarily impress this group. But you can safely
>> expect to see questions in the future from Sun
>> worshipers 8^).
>
> Exactly.
>
>>
>>
>> So there is still a lot unresolved in the discussion.
>>
>> I expect that in the long run Scott Ambler's design
>> will become standard-practice in the industry. For
>> this reason I'm mostly in support of Jason's
>> suggestion.
>>
>> When last we spoke about this subject, Jason mentioned
>> having some code in his hands that implements Ambler's
>> design in Java. Jason, have you made any progress on
>> the code from player.sourceforge.net, etc? It would be
>> good to hear your impressions.
>>
>> -Eric
>
> fedor.
>
> -------------------------------
> Amicus Plato amicus Aristoteles magis amica veritas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
