[Note: It helps to view this email in monospace!]
I am part way through the job of refactoring Hibernate so that
SQL generation occurs in its own layer. The current internal
architecture is something along the lines of:
========================================
API Layer (interfaces only)
========================================
Behaviour Layer
(Persistence Semantics)
========================================
Services | O/R
Layer | Mapping Layer
========================================
JDBC/JNDI/JTA
========================================
(Note that Hibernate does not implement this architecture
*absolutely* correctly, but it does come pretty close.)
In this design, SQL generation occurs inside the O/R Mapping
Layer (the Persisters, Loaders and QueryTranslator). My eventual
endpoint would look something more like the following:
========================================
API Layer (interfaces only)
========================================
Behaviour Layer
(Persistence Semantics)
========================================
| O/R
Services | Mapping Layer
Layer |======================
| SQL Generation
| Layer
========================================
JDBC/JNDI/JTA
========================================
In this design, generation of actual SQL query strings is factored
out of the code that implements O/R mapping logic. Of course, in
hindsight, if you were designing a persistence layer, you would
probably think to do it this way upfront. However, Hibernate was
developed following the principle of "the simplest thing that
could possibly work" which was good in some cases, bad in others.
The main benefit of the proposed refactoring is simply to make the
O/R Mapping code more readable. I don't think a fully correct
layering can be achieved in the immediate future but there is some
low-hanging fruit that I have already done and I will attempt to
extend the new model to the QueryTranslator stuff ASAP.
**********************************************************************
Any personal or sensitive information contained in this email and
attachments must be handled in accordance with the Victorian Information
Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988
(Commonwealth), as applicable.
This email, including all attachments, is confidential. If you are not the
intended recipient, you must not disclose, distribute, copy or use the
information contained in this email or attachments. Any confidentiality or
privilege is not waived or lost because this email has been sent to you in
error. If you have received it in error, please let us know by reply
email, delete it from your system and destroy any copies.
**********************************************************************
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
hibernate-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
