List Info

Thread: Abstracting Mappers
Abstracting Mappers
country flaguser name
United States		 2008-04-22 07:48:05 

  


  

    Hello,

 

I am just getting my feet wet with Ibatis.Net, and have a few questions. I noticed in the older tutorial docs (1.2.1), there was a suggestion to create helper classes for each mapper. That way you could wrap all of the CRUD operations in a unified fashion. I liked this, for one because it would be easy to mock this and test interaction rather than testing directly against DB calls. However, there was another suggestion to create all of the helpers as singletons, which I'm not crazy about.

 

I was curious to know how other developers approach the issues of abstracting the mappers for testing and development in general. 

 

Thanks,

S.
Spell a grand slam in this game where word skill meets World Series. Get in the game.		
  

  
  
   
     
    

  

    Re: Abstracting Mappers
  


  

     user name

     2008-04-22 07:57:37
  


  

    
On Tue, Apr 22, 2008 at 8:48 AM, Sal Bass <salbass575hotmail.com> wrote:
>
> I was curious to know how other developers approach the
issues of
> abstracting the mappers for testing and development in
general.
>

I share your dislike of singletons.  Instead, I would
recommend a
service layer that knows the specifics of performing CRUD
operations
on simple model objects.  Then look at something like spring
to tie it
all together.

Ideally only the service layer would even know about iBatis
in this
implementation.  That leaves you free to test or swap
implementations,
or work around later issues with the API.

Sheldon



  


  

    
  

  
  
   
     
    

  

    RE: Abstracting Mappers
  


  

     country flaguser name
United States		
     2008-04-22 08:39:20
  


  

    

  


  

    Yes, I do like the service layer idea better. The only caveat is that I need a service layer class for every domain class, which could get unwieldy. We currently use an active record style approach, but I really want PI domain objects. I also loathe writing ADO.NET code. Because we use sprocs here, I figure Ibatis will remove the ado.net, while giving me PI objects. The downside is that if I want abstraction (I do), I need a service class for each domain object.






> Date: Tue, 22 Apr 2008 08:57:37 -0400
> From: sheldonbgmail.com
> To: user-csibatis.apache.org
>; Subject: Re: Abstracting Mappers
&gt; 
> On Tue, Apr 22, 2008 at 8:48 AM, Sal Bass <salbass575hotmail.com> wrote:
>; >
> > I was curious to know how other developers approach the issues of
> > abstracting the mappers for testing and development in general.
&gt; >
> 
> I share your dislike of singletons. Instead, I would recommend a
> service layer that knows the specifics of performing CRUD operations
> on simple model objects. Then look at something like spring to tie it
> all together.
> 
> Ideally only the service layer would even know about iBatis in this
> implementation. That leaves you free to test or swap implementations,
> or work around later issues with the API.
> 
> Sheldon

In a rush? Get real-time answers with Windows Live Messenger.		
  

  
  
   
     
    

  

    Re: Abstracting Mappers
  


  

     user name

     2008-04-22 09:54:23
  


  

    
On Tue, Apr 22, 2008 at 9:39 AM, Sal Bass <salbass575hotmail.com> wrote:
>
 The
> downside is that if I want abstraction (I do), I need a
service class for
> each domain object.
>

In practice, is that true?  I find you end up working on
object
graphs, not individual objects, so a service class would
know how to
operate on a group of objects, not just a single object. 
But you are
correct, it can be a verbose pattern to implement.

Sheldon



  


  

    
  

  
  
   
     
    

  

    RE: Abstracting Mappers
  


  

     country flaguser name
United States		
     2008-04-22 12:47:42
  


  

    

  


  

    You are correct. I have limited experience using the service layer pattern. Having it focus on the object graph does make more sense.

&nbsp;

I just wonder about a scenario where a developer needs to get a list of domain objects, and a service class may be overkill. I don't think I want him/her just calling the mappers from the presentation layer, but I'm not sure. Perhaps a less dogmatic approach is advisable. However, because I want unit testing, I really want the mapping interaction to be abstracted for testing/mocking purposes. I am also trying to get all infrastructure related concerns out of our presentation layer. That I won't bend on 





&nbsp;






> Date: Tue, 22 Apr 2008 10:54:23 -0400
> From: sheldonbgmail.com
> To: user-csibatis.apache.org
>; Subject: Re: Abstracting Mappers
&gt; 
> On Tue, Apr 22, 2008 at 9:39 AM, Sal Bass <salbass575hotmail.com> wrote:
>; >
> The
> > downside is that if I want abstraction (I do), I need a service class for
> > each domain object.
&gt; >
> 
> In practice, is that true? I find you end up working on object
>; graphs, not individual objects, so a service class would know how to
> operate on a group of objects, not just a single object. But you are
> correct, it can be a verbose pattern to implement.
> 
> Sheldon


Spell a grand slam in this game where word skill meets World Series. Get in the game.		
  

  
  
   
     
    






 [1-5]











   
 





about | contact  Other archives ( Real Estate discussion Medical topics )