ibatis-user-cs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlos Peix" <peix-lis...@praxia.com.ar>
Subject RE: Kind of architecture question
Date Tue, 08 May 2007 13:09:32 GMT
Hi Samuel,
Yes, you're right, in fact NHibernate is my other preferred tool but I like
IBatis flexibility and performance. I just resisted to believe that all the
developers using IBatis managed to manually solve the "multiple instances"
I heard that there are users asking for some kind of hook into IBatis object
instantiation to implement this kind of stateful operation.
Thanks for taking the time to answer.
Carlos Peix


From: Clough, Samuel (USPC.PRG.Atlanta) [mailto:Samuel_Clough@princetonrg.com] 
Sent: Martes, 08 de Mayo de 2007 08:47 a.m.
To: user-cs@ibatis.apache.org
Subject: RE: Kind of architecture question

Not to sound smart or anything, but if you need to ensure that you have only one
ref for each logical object, have you considered NHibernate?  iBatis is designed
to work in the way it is working.  It allows you to write something very similar
to a custom DAO without doing all the heavy lifting.  What you are doing sounds
to me like a perfect NHibernate use case.  NHibernate enforces that only one
actual reference exists in the session for a specific object.
As you've mentioned, you could tweak the iBatis caching but I'm not sure if
that's going to give you want you want completely.
To me iBatis is perfect for a more high-performance, stateless type of world
that I typically work in (although it works in a stateful world as well).
NHibernate is better suited for that more stateful world.  (This is not to say
that there aren't crossover areas where you can use either one because there


From: Carlos Peix [mailto:peix-listas@praxia.com.ar] 
Sent: Tuesday, May 08, 2007 7:31 AM
To: user-cs@ibatis.apache.org
Subject: Kind of architecture question

Hi Shane,
I heard the "no access to repository from the domain objects" idea but I can't
do that in my daily work, I need to access repository from my domain. Besides
that, I use interfaces for all my repositories and I maintain the implementation
out of the domain model (reflection or DI is my glue), so I'm OK with that. I
just use the service layer to start and commit transactions.
Regarding if my main concern is an IBatis issue or not, I was told that IBatis
don't want to mess with internal identity maps and I can see why. It need ton
control object identity, concurrency, object context, etc.
I just want to know how the many programmers that use IBatis cope with that


From: Shane Courtrille [mailto:shanecourtrille@gmail.com] 
Sent: Lunes, 07 de Mayo de 2007 07:34 p.m.
To: peix-listas@praxia.com.ar
Subject: Re: Kind of architecture question

Hey, Carlos.

Yes, I guess the name for it would be Identity Map.  I have a real concern with
having my domain objects call to my repository.  In my world that's the job of
my service layer.  To provide the "glue" that brings my domain and technical
services together.  But at the same time it would definitely solve this issue.  

I do think I disagree with this not being an iBatis issue.  My understanding is
that iBatis is suppose to provide a simple mapping solution that resolves 80% of
the work with 20% of the code.  I don't see how you can consider something this
simple as not being a very important part of that 80%.  I'm definitely looking
forward to a better solution to this problem if anyone can come up with one. 


On 5/7/07, Carlos Peix <peix-listas@praxia.com.ar> wrote: 

Hi Shane, thanks for taking the time to answer.
Yes, you are talking about an Identity Map I guess, but this solution is harder
to implement and tune. It's my last resort though.
Of course, definitely the select="CustomerById" needs to be removed. In fact,
the command CustomerById uses a different cache that the command CustomerAll so,
if we use cache for both commands we can stop IBatis building different
One approach I used is for resolving this is implementing the
CustomerRepository.GetAll() with an IBatis query (cached) and the
CustomerRepository.GetById() resolved in memory. But I'm not very happy with
this solution either
Of course, the Order ResultMap just get the Customer Id and I resolve the
property getter or setter that way.
class Order {
    // This field is mapped in IBatis
    object customerId;
    // this is a transient field
    private Customer customer;
    public Customer Customer
        get {
            if ( customer == null )
                customer = CustomerRepository.GetById( customerId );

            return customer;

        set { customerId = value.Id; }


From: Shane Courtrille [mailto:shanecourtrille@gmail.com] 
Sent: Lunes, 07 de Mayo de 2007 07:03 p.m.
To: user-cs@ibatis.apache.org; peix-listas@praxia.com.ar
Subject: Re: Kind of architecture question

I'm just learning iBatis.Net now but I have used the repository <-> mapper
pattern in the past.  Usually what I have done is have the repository contain a
reference to a cache.  It checks the cache before using the mapping layer to
retrieve the item.  The problem I see is your Order select="CustomerById".
Without knowing more about iBatis I would suggest you may need to remove that
and instead have your repository fill in the reference after it gets the Order.
Definitely not a solution I'm in love with though. 


On 5/7/07, Carlos Peix <peix-listas@praxia.com.ar> wrote: 

Hi all,
I used IBatis.NET with success in various projects now but I am still not very
happy with my implementations. I'll try to explain my concerns.
My environment is .NET 1.1 but I think .NET 2.0 is the same thing. I should say
that I try to work guided by the DDD principles, so I access the final store
through repositories.
I have, for example, an entity Customer (aggregate root or simply a persistent
identifiable object) and a CustomerRepository with the following interface:
Customer CustomerRepository.GetById( object id );

IList CustomerRepository.GetAll(); 
and I also have a Order and OrderRepository with the following interface
OrderRepository.GetByNumber( int number );

The problem I face all the time with IBatis is the I get different instances if
I do:
// implemented with a Mapper.QueryForObject( "CustomerById", id );
Customer customer1 = CustomerRepository.GetById( object id );

// implemented with a Mapper.QueryForList( "CustomerAll" );
Customer customer2 = CustomerRepository.GetAll()[0]; 


// implemented with a Mapper.QueryForObject( "OrderByNumber", number );
// and Customer mapped this way in the OrderResultMap:
//  <result property="customer" column="CustomerId" select="CustomerById" />
Customer customer3 = OrderRepository.GetByNumber( 100 ).Customer;
But customer1.Id, customer2.Id and customer3.Id are the same.
Ok, this is a situation that need to be controlled, otherwise I could modify or
check different instances of the same object. I was told previously that this is
not an IBatis problem and I see why (in fact IBatis doesn't know anything about
object identity, so it can't control this).
The question is: how are you structuring your code to control that situation?
there are some "recommended practices"? I started with some ideas (one of them
include IBatis cache configuration) but I'm not happy with any of them.
Sorry about the long post and thanks in advance.

Carlos Peix


Princeton Retirement Group, Inc - Important Terms 

This E-mail is not intended for distribution to, or use by, any person or entity
in any location where such distribution or use would be contrary to law or
regulation, or which would subject Princeton Retirement Group, Inc. or any
affiliate to any registration requirement within such location. 

This E-mail may contain privileged or confidential information or may otherwise
be protected by work product immunity or other legal rules. No confidentiality
or privilege is waived or lost by any mistransmission. Access, copying or re-use
of information by non-intended or non-authorized recipients is prohibited. If
you are not an intended recipient of this E-mail, please notify the sender,
delete it and do not read, act upon, print, disclose, copy, retain or
redistribute any portion of this E-mail. 

The transmission and content of this E-mail cannot be guaranteed to be secure or
error-free. Therefore, we cannot represent that the information in this E-mail
is complete, accurate, uncorrupted, timely or free of viruses, and Princeton
Retirement Group, Inc. cannot accept any liability for E-mails that have been
altered in the course of delivery. Princeton Retirement Group, Inc. reserves the
right to monitor, review and retain all electronic communications, including
E-mail, traveling through its networks and systems (subject to and in accordance
with local laws). If any of your details are incorrect or if you no longer wish
to receive mailings such as this by E-mail please contact the sender by reply


View raw message