--- Max Rudman <[EMAIL PROTECTED]> wrote:
>
> On Dec 17, 2004, at 8:52 PM, David Graham wrote:
>
> > There aren't any reusable implementations that I can think of. What
> do
> > you picture the Hibernate mapper implementation looking like?
> Well, I am not too familiar with other O/R implementations but at least
> in Hibernate you don't need a separate Data Access Object (DAO)
> implementation for each value object. Everything needed to persist and
> load Person is captured in Person.hbm.xml mapping file.
>
> What I have in mind for Hibernate implementation is HibernateMapper
> class which will hold on to Hibernate Session object and Class of the
> entity being persisted. HibernateMapperFactory then would simply pass
> through entity class to the Mapper so it can in turn use it in its
> calls to Hibernate Session. It would look something like this:
>
> public class HibernateMapper implements Mapper {
> private net.sf.hibernate.Session session;
> private Class type;
>
> public HibernateMapper(Session session, Class type) {
> this.session = session;
> this.type = type;
> }
>
> public Object findByUniqueId(Object id) {
> return session.get(type, id);
> }
>
> .....
>
> }
>
> This is probably very oversimplified and there is a fair amount of
> "housekeeping" code; hence, the value of providing an implementation as
> part of the Mapper project instead of forcing users to re-invent the
> wheel so to speak.
>
> In addition, we could provide an implementation which works with Spring
> Framework, for example, which is an IoC container I am very fond of.
> That way, the whole MapperFactory configuration can be done out of XML
> config files and provided to business logic classes in the "Injection
> of Dependency" manner. As a bonus, Spring integrates with Hibernate to
> provide automatic transaction management and such.
>
> I imagine something similar can be done for other O/R frameworks; I am
> just not familiar enough with them to give you more details.
>
> > Mapper really saved me on one project where we designed a new db
> schema
> > and wrote a bunch of code to access it and then mgmt. decided to use
> > the
> > old schema at the last minute. All I had to do was implement the
> > mappers
> > differently and the rest of the app. never changed.
>
> I agree, O/R tools are great but being able to switch to a different DB
> schema is a virtue of the O/R mapping tool itself not the abstraction
> API like Mapper. In other words, it seems to me I could have achieved
> the same result by using Hibernate directly as opposed to hard-coding
> DB schema in JDBC calls.
In my particular example certain tables did not exist in the old schema so
I had to simulate them with XML files. The mapper implementation read
from XML instead of the database. Hibernate is a wonderful tool but it
needs database tables :-).
> If I understood the project's goal correctly,
> it is to abstract various O/R implementations in a manner similar to
> how Commons Logging abstracts various Logging implementations.
The idea behind Mapper is insulating the application from the details of
data retrieval including SQL, HQL, etc. The app. just calls
PersonMapper.findByFirstName() and the implementation uses SQL, HQL, or
queries XML as needed. The implementation may not be using a relational
database at all.
David
>
> Max
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
