You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Giorgio Vespucci <gi...@gmail.com> on 2010/05/07 15:29:15 UTC
Injecting an iBatis DAO
Hi all
My question is about if an iBatis Dao can be injected in a non-DAO class to
use its services.
Can I write so?
<pre>
public SomeThing methodOfNonDaoClass() {
try {
dao.startTransaction();
dao.startBatch();
<some non-dao work on myData>
dao.insertXXXX(myData);
for() {
dao.updateXXXX()
}
dao.executeBatch();
dao.commitTransaction();
} catch (Exception e) {
e.printStackTrace();
} finally{
try {
dao.endTransaction();
} catch (SQLException e) {
e.printStackTrace();
}
}
return someThing;
}
</pre>
The dao instance has been injected in NonDaoClass after construction.
The big question is if the transactional context works also "I am not" in
the DAO code.
Thank you all
--
Giorgio Vespucci
giorgio [dot] vespucci [at] gmail [dot] com
Skype, Twitter, Slideshare: gvespucci
Linux User #471792
http://xpermanwalking.blogspot.com
Re: Injecting an iBatis DAO
Posted by Giorgio Vespucci <gi...@gmail.com>.
2010/5/8 Larry Meadors <la...@gmail.com>
> On Fri, May 7, 2010 at 8:21 PM, Maciej Radochonski
> <mr...@gmail.com> wrote:
> > From technical point of view it is ok, but I would suggest to keep all
> the
> > database related code in DAO class, because what are you doing here is
> > mixing two layers that should be kept separate, BO and DAO.
>
> I couldn't disagree more. :)
>
> I think it's totally OK to put transactional logic outside of the data
> access layer - it keeps the data access code simpler, and it's still
> trivial to unit test with mock
>
I'm trying now to use declarative transaction approach, because I'm using
Spring 3.0.2, so the Dao doesn't matter if it's in a transaction or not, but
I still need using startBatch() and executeBacth(), because my insert(data)
can be thousands! :)
Is it still feasable/correct the approach to inject the DAO?
Indeed I do not want mix the two logic, but the constraint is to do all the
work in one single loop.
I'm reading lots of line from a BufferedReader and I would analyze and save,
and eventually commit/rollbak at the end of the loop.
--
Giorgio Vespucci
giorgio [dot] vespucci [at] gmail [dot] com
Skype, Twitter, Slideshare: gvespucci
Linux User #471792
http://xpermanwalking.blogspot.com
Re: Injecting an iBatis DAO
Posted by Larry Meadors <la...@gmail.com>.
On Fri, May 7, 2010 at 8:21 PM, Maciej Radochonski
<mr...@gmail.com> wrote:
> From technical point of view it is ok, but I would suggest to keep all the
> database related code in DAO class, because what are you doing here is
> mixing two layers that should be kept separate, BO and DAO.
I couldn't disagree more. :)
I think it's totally OK to put transactional logic outside of the data
access layer - it keeps the data access code simpler, and it's still
trivial to unit test with mocks.
Larry
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: Injecting an iBatis DAO
Posted by Maciej Radochonski <mr...@gmail.com>.
>From technical point of view it is ok, but I would suggest to keep all the
database related code in DAO class, because what are you doing here is
mixing two layers that should be kept separate, BO and DAO.
Regards,
Maciej
On Fri, May 7, 2010 at 10:15 PM, Larry Meadors <la...@gmail.com>wrote:
> Yes.
>
> On Fri, May 7, 2010 at 7:29 AM, Giorgio Vespucci
> <gi...@gmail.com> wrote:
> > Hi all
> >
> > My question is about if an iBatis Dao can be injected in a non-DAO class
> to
> > use its services.
> >
> > Can I write so?
> >
> > <pre>
> > public SomeThing methodOfNonDaoClass() {
> >
> > try {
> > dao.startTransaction();
> > dao.startBatch();
> >
> > <some non-dao work on myData>
> >
> > dao.insertXXXX(myData);
> >
> > for() {
> > dao.updateXXXX()
> > }
> >
> > dao.executeBatch();
> > dao.commitTransaction();
> >
> > } catch (Exception e) {
> > e.printStackTrace();
> > } finally{
> > try {
> > dao.endTransaction();
> > } catch (SQLException e) {
> > e.printStackTrace();
> >
> > }
> > }
> >
> >
> > return someThing;
> > }
> > </pre>
> >
> > The dao instance has been injected in NonDaoClass after construction.
> >
> > The big question is if the transactional context works also "I am not" in
> > the DAO code.
> >
> > Thank you all
> > --
> > Giorgio Vespucci
> > giorgio [dot] vespucci [at] gmail [dot] com
> > Skype, Twitter, Slideshare: gvespucci
> > Linux User #471792
> > http://xpermanwalking.blogspot.com
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
Re: Injecting an iBatis DAO
Posted by Larry Meadors <la...@gmail.com>.
Yes.
On Fri, May 7, 2010 at 7:29 AM, Giorgio Vespucci
<gi...@gmail.com> wrote:
> Hi all
>
> My question is about if an iBatis Dao can be injected in a non-DAO class to
> use its services.
>
> Can I write so?
>
> <pre>
> public SomeThing methodOfNonDaoClass() {
>
> try {
> dao.startTransaction();
> dao.startBatch();
>
> <some non-dao work on myData>
>
> dao.insertXXXX(myData);
>
> for() {
> dao.updateXXXX()
> }
>
> dao.executeBatch();
> dao.commitTransaction();
>
> } catch (Exception e) {
> e.printStackTrace();
> } finally{
> try {
> dao.endTransaction();
> } catch (SQLException e) {
> e.printStackTrace();
>
> }
> }
>
>
> return someThing;
> }
> </pre>
>
> The dao instance has been injected in NonDaoClass after construction.
>
> The big question is if the transactional context works also "I am not" in
> the DAO code.
>
> Thank you all
> --
> Giorgio Vespucci
> giorgio [dot] vespucci [at] gmail [dot] com
> Skype, Twitter, Slideshare: gvespucci
> Linux User #471792
> http://xpermanwalking.blogspot.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org