"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 <[EMAIL PROTECTED]> wrote:
> Sorry, I accidentally replied to Nathan only.
>
> ---------- Forwarded message ----------
> From: Clinton Begin <[EMAIL PROTECTED] >
> Date: May 29, 2005 9:56 AM
> Subject: Re: Support for generics
> To: Nathan Maves <[EMAIL PROTECTED]>
>
>
> 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 <[EMAIL PROTECTED] > 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED] > 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
> > >> >> >>
> > >> >> >>
> > >> >> >
> > >> >>
> > >>
> >
> >
>
>
