You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Rajat Pandit <ra...@centergroupinc.com> on 2003/10/24 19:35:30 UTC
Db usage in bean [design issue]
Hello all,
I am new to servlets development as such. And have this design issue. I
want to ensure that the applications that I build can be used with other
databases, which might have different tables or column names or
different structures on the whole.
I mean the basic buisness logic remains the same and other things around
it might change. This is what I am doing right now.
My Action - extended - Struts Action -> the execute / perform method
calls the buisness logic bean.
The buisness logic bean is passed the connection resource (orginally
created in the action bean itself).
This connection resource is used by the methods inside the bean for
getting their data.
I am not sure, but is there a possibility that I have buisness beans in
such a way that they don't have anytihng to do with the database
connection and all they need is data as arguments and return data back
_AND_ I am also don't need to clutter up my (extended) action class with
SQL fetches!.
This essentially means that there will be
A. a buisness logic bean. Which contains the buisness logic to do
datamanipulation.
B. a database <put ur technical name here> bean which does the work of
fetching and returning back data to the db.
C. an extended action class which manages both of these.
All this might sound rather silly, but there are times when I really
drive my self nuts about keeping all the tiers clean and independent of
each other.
Can someone shed some light on this. (other alternatives being, turn on
the floodlights ;) )
Also any pointers on design patterns...
Rajat Pandit | rajatp@centergroupinc.com
+91 612 3117606
[ Developer and Part Time Human Being]
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Db usage in bean [design issue]
Posted by Rajat Pandit <ra...@centergroupinc.com>.
Thanks a lot ted, you just put them in the right words, this is exactely
what I need. I am on it rightaway!
-----Original Message-----
From: Ted Husted [mailto:husted@apache.org]
Sent: Friday, October 24, 2003 11:23 AM
To: Struts Users Mailing List
Subject: Re: Db usage in bean [design issue]
My very best advice is to have a look at the iBATIS DAO framework
<http://ibatis.com>. For the time being, it's bundled with the iBATIS
SqlMap package, but you don't need to use them together. It uses the
same general pattern you see in the current Struts MailReader example,
but raises the DAO pattern to a reusable framework.
While DAO is an acromym for Data Access Object, the current trend is
toward a data access API (all action no data) coupled with a data
transfer object (all properties, no actions). This is the strategy that
the Struts Mailreader uses, to good effect.
HTH, Ted.
Rajat Pandit wrote:
> Hello all,
> I am new to servlets development as such. And have this design issue.
> I want to ensure that the applications that I build can be used with
> other databases, which might have different tables or column names or
> different structures on the whole.
>
> I mean the basic buisness logic remains the same and other things
> around it might change. This is what I am doing right now.
>
> My Action - extended - Struts Action -> the execute / perform method
> calls the buisness logic bean.
>
> The buisness logic bean is passed the connection resource (orginally
> created in the action bean itself).
>
> This connection resource is used by the methods inside the bean for
> getting their data.
>
> I am not sure, but is there a possibility that I have buisness beans
> in such a way that they don't have anytihng to do with the database
> connection and all they need is data as arguments and return data back
> _AND_ I am also don't need to clutter up my (extended) action class
> with SQL fetches!.
>
> This essentially means that there will be
> A. a buisness logic bean. Which contains the buisness logic to do
> datamanipulation.
> B. a database <put ur technical name here> bean which does the work of
> fetching and returning back data to the db.
> C. an extended action class which manages both of these.
>
>
> All this might sound rather silly, but there are times when I really
> drive my self nuts about keeping all the tiers clean and independent
> of each other.
>
> Can someone shed some light on this. (other alternatives being, turn
> on the floodlights ;) )
>
> Also any pointers on design patterns...
>
> Rajat Pandit | rajatp@centergroupinc.com
> +91 612 3117606
> [ Developer and Part Time Human Being]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
--
Ted Husted,
Junit in Action - <http://www.manning.com/massol/>,
Struts in Action - <http://husted.com/struts/book.html>,
JSP Site Design -
<http://www.amazon.com/exec/obidos/ISBN=1861005512>.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Db usage in bean [design issue]
Posted by Ted Husted <hu...@apache.org>.
My very best advice is to have a look at the iBATIS DAO framework
<http://ibatis.com>. For the time being, it's bundled with the iBATIS
SqlMap package, but you don't need to use them together. It uses the
same general pattern you see in the current Struts MailReader example,
but raises the DAO pattern to a reusable framework.
While DAO is an acromym for Data Access Object, the current trend is
toward a data access API (all action no data) coupled with a data
transfer object (all properties, no actions). This is the strategy that
the Struts Mailreader uses, to good effect.
HTH, Ted.
Rajat Pandit wrote:
> Hello all,
> I am new to servlets development as such. And have this design issue. I
> want to ensure that the applications that I build can be used with other
> databases, which might have different tables or column names or
> different structures on the whole.
>
> I mean the basic buisness logic remains the same and other things around
> it might change. This is what I am doing right now.
>
> My Action - extended - Struts Action -> the execute / perform method
> calls the buisness logic bean.
>
> The buisness logic bean is passed the connection resource (orginally
> created in the action bean itself).
>
> This connection resource is used by the methods inside the bean for
> getting their data.
>
> I am not sure, but is there a possibility that I have buisness beans in
> such a way that they don't have anytihng to do with the database
> connection and all they need is data as arguments and return data back
> _AND_ I am also don't need to clutter up my (extended) action class with
> SQL fetches!.
>
> This essentially means that there will be
> A. a buisness logic bean. Which contains the buisness logic to do
> datamanipulation.
> B. a database <put ur technical name here> bean which does the work of
> fetching and returning back data to the db.
> C. an extended action class which manages both of these.
>
>
> All this might sound rather silly, but there are times when I really
> drive my self nuts about keeping all the tiers clean and independent of
> each other.
>
> Can someone shed some light on this. (other alternatives being, turn on
> the floodlights ;) )
>
> Also any pointers on design patterns...
>
> Rajat Pandit | rajatp@centergroupinc.com
> +91 612 3117606
> [ Developer and Part Time Human Being]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
--
Ted Husted,
Junit in Action - <http://www.manning.com/massol/>,
Struts in Action - <http://husted.com/struts/book.html>,
JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org