ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brandon Goodin <brandon.goo...@gmail.com>
Subject Re: Support for generics
Date Sun, 29 May 2005 20:10:11 GMT
"If I were to ditch a layer in this 5 layer cake, I'd ditch the DAOs.  :-)"

Well, i wounldn't say ditch the DAO layer. I'd say make the Mapping
interface your DAO layer.

"I'm personally not a fan of code generation at all."

I believe it would be possible to create a tool that makes the
creation and maintenance of the mapping interface easier. Currently I
have begun prototyping an iBatis GUI tool. I do not like build time
code generation with Ant. But, I DO like incremental and intentional
code generation that cuts down on keystrokes. I think we can all
appreciate the setter/getter code generation in each of our favorite
IDEs. The iBatis GUI looks to be that kind of tool for iBatis
development.

Brandon

On 5/29/05, Clinton Begin <clinton.begin@gmail.com> wrote:
> Sorry, I accidentally replied to Nathan only.
> 
> ---------- Forwarded message ----------
> From: Clinton Begin <clinton.begin@gmail.com >
> Date: May 29, 2005 9:56 AM
> Subject: Re: Support for generics
> To: Nathan Maves <Nathan.Maves@sun.com>
> 
> 
>  I understand that that is possible.  I'm personally not a fan of code
> generation at all.  In this case I think it would be especially impractical.
>  I've never just sat down and coded all of my SQL mapping files up front,
> which would be necessary if we were to generate the interface.  I suppose we
> could regenerate it after each change, but what a yucky programming
> paradigm.  By the time we've set up the Ant build, the SQL Mapper interface
> generator task, and all of our SQL Maps, I could have typed a lot of
> interfaces!
>  
>  I think one of the best benefits of this approach is that you can very
> easily test drive your persistence layer.  
>  
>  You can start with a test:
>  
>  public void testShouldGetDocumentWithIDofOne () {
>      DocumentMapper mapper = new MockDocumentMapper(); //or use your
> favourite mocking framework
>      Document doc = mapper.getDocument(i);
>      assertNotNull (doc);
>      assertEquals (1, doc.getId());
>  }
>  
>  You can create the interface and the mock:
>  
>  public interface DocumentMapper {
>      Document getDocument (int id);
>  }
>  
>  public class MockDocumentMapper implements DocumentMapper {
>      public Document getDocument (int id) {
>          return new Document (id);
>      }
>  }
> 
>  All without an SqlMapClient.  Of course all we're really testing in this
> example is an interface, but what this allows you to do is more easily test
> of consumers of the mapping layer (DAOs).  For example, if you have a DAO
> that depends on a Mapper, you can more easily test the DAO without an
> SqlMapClient instance (or any persistence related mocks):
>  
>  public class SqlMapDocumentDao extends SqlMapDaoTemplate {
>  
>    private DocumentMapper documentMapper;
>  
>    // Used by the DAO framework
>    public SqlMapDocumentDao (DaoManager daoManager) {
>      super(daoManager); 
>      // this next method isn't part of the DAO template yet
>      documentMapper = (DocumentMapper) getMapper(DocumentMapper.class);
>    }
>  
>    // Used by unit tests
>    public SqlMapDocumentDao (DocumentMapper documentMapper) {
>      this.documentMapper = documentMapper;
>    } 
>  
>  }
>  
>  I know it looks like a lot of code, and indeed we'd want to question the
> value of using both DAO and Mapper interfaces (too much abstraction).  The
> testing approach described above works just as well at the service layer
> (i.e. without DAOs), or even at the presentation layer (i.e. without a
> service layer -spank!).  I think this gives us a cleaner alternative model
> for when we don't use DAOs, and a more layered model if we want maximum
> abstraction (limited value, but it's there).
>  
>  If I were to ditch a layer in this 5 layer cake, I'd ditch the DAOs.  :-)
> 
>  
>  Cheers,
>  Clinton
>  
>  
> On 5/28/05, Nathan Maves <Nathan.Maves@sun.com > wrote:
> > Clinton,
> > 
> > First off thanks.  I will get it a go this week.
> > 
> > As per Fabrizio response to the email below, I agree that this process
> > of creating interfaces is too programatic.  By that it would seem to me
> > that these interfaces could be created automatically when parsing the
> > sql map files.  All you would need to do is create a method based on
> > the id, resultClass and the parameterClass.
> > 
> > Am I way of in thinking this? 
> > 
> > Nathan
> > 
> > On May 28, 2005, at 10:36 PM, Clinton Begin wrote:
> > 
> > >
> > >
> http://www.mail-archive.com/ibatis-user-java@incubator.apache.org/
> > > msg02403.html
> > >
> > >  Cheers,
> > >  Clinton
> > >
> > > On 5/28/05, Nathan Maves < Nathan.Maves@sun.com> wrote:
> > >> to use the Mapper binding functionality. 
> > >>
> > >> Nathan
> > >>
> > >> On May 27, 2005, at 8:32 PM, Clinton Begin wrote:
> > >>
> > >> >
> > >> >I believe the new Mapper binding functionality would resolve
> > >> this.... 
> > >> >
> > >> >Nathan, are you up for trying it out?
> > >> >
> > >> >Cheers,
> > >> >Clinton
> > >> >
> > >> >
> > >> > On 5/27/05, Nathan Maves < Nathan.Maves@sun.com> wrote:
> > >> >> gets to the DAO layer.
> > >> >>
> > >> >> You can cast the List but you will always get the warning for
and
> > >> >> unchecked assignment when the List is returned from the sqlmap.

> > >> >>
> > >> >> List<Student> students =
> (List<Student>)executeQueryForList
> > >> >> ("getStudents",null);
> > >> >>
> > >> >> Looks good but does not resolve the warnings. 
> > >> >>
> > >> >> Nathan
> > >> >>
> > >> >>
> > >> >> On May 27, 2005, at 2:30 PM, Larry Meadors wrote:
> > >> >>
> > >> >> > I have done that with my DAO layer. 
> > >> >> >
> > >> >> > SqlMap returns it as List, but you can cast it.
> > >> >> >
> > >> >> > Worked great. :)
> > >> >> >
> > >> >> > Larry 
> > >> >> >
> > >> >> >
> > >> >> > On 5/27/05, Nathan Maves < Nathan.Maves@sun.com > wrote:
> > >> >> >
> > >> >> >> Since apple is taking then sweet time I just got Java
1.5.I am
> > >> >> >> diving in head first but I am curious about what the
plans for
> > >> >> >> Generics are.
> > >> >> >>
> > >> >> >> Will I batis support them? 
> > >> >> >> Could there be a way to specify the list type instead
of Object?
> > >> >> >>
> > >> >> >> i.e.
> > >> >> >> return a List<Student> back based on the result
class of the 
> > >> query?
> > >> >> >>
> > >> >> >> Nathan
> > >> >> >>
> > >> >> >>
> > >> >> >
> > >> >>
> > >>
> > 
> > 
>  
>

Mime
View raw message