ibatis-user-cs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nguyen, Tom" <Tom.Ngu...@rels.info>
Subject RE: Kind of architecture question
Date Tue, 08 May 2007 14:28:24 GMT
I agreed with Sam that this should not be a concern for iBatis.  I've
also battled with the same issues in the pass, but I've found that it's
much easier to use SQL for controlling of identity and concurrency
(through various methods such as comparison of OriginalValue or
LastModifiedDate).

 

Repository implementation is a can of worm in itself.  I prefer to use
light weight object and don't have to worry about issues such as
multi-threading, caching and releasing references for Garbage Collector
when it's not being reference.  Also, you can't really ensure identical
object references in a webfarm or multiple application server SOA
implementation.

 

On the other hand, I had a very specific need of repository base on
lookup business objects such as OrderType, BusinessType, ContactType,
etc...  In this case, I implement custom in-memory caching (repository).
It's a very specific implementation which allow me to lazy load objects
by identity (key) and type, cache, timely clearing of cache for GC,
etc..

 

Regards,


Tom Nguyen 
Sr. Developer



________________________________

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

 

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" problem.

 

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 are).

	 

	
________________________________


	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 problem.

	 

	Thanks

	 

	Carlos

		 

		
________________________________


		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. 
		
		Shane

		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 instances.

		 

		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; }

		    }

		 

		}

		 

		Carlos

			 

			
________________________________


			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. 
			
			Shane

			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 E-mail. 

	
________________________________



************************************************************************************
This e-mail message and any files transmitted herewith, are intended solely for the
use of the individual(s) addressed and may contain confidential, proprietary or 
privileged information.  If you are not the addressee indicated in this message 
(or responsible for delivery of this message to such person) you may not review, 
use, disclose or distribute this message or any files transmitted herewith.  If you 
receive this message in error, please contact the sender by reply e-mail and delete
this message and all copies of it from your system.
************************************************************************************

Mime
View raw message