Rick Reumann wrote:
Vic, not sure if I'm getting your replies to the list, so if you reply to this could you reply to me as well. Thanks a lot!
On Mon, 17 Mar 2003 14:00:15 -0500 Vic Cekvenich <[EMAIL PROTECTED]> wrote:
and why baseBean has a DAO helper is a best practice (amoung other things I showed).
Is the DAO helper in the latest basicPortal? I haven't downloaded from CVS the very latest bp but am looking at the bp that you can download from basebeans.com and am not sure what represents the DAO helper in that application (if there is even an example of one there?).
Bean has a DAO property, that it delegatesto.
Using the RowSet approach, unless I'm wrong the DAO portion that has the get and set implementations are found in BasicDAOImpl:
public String getProperty(String property) throws SQLException { Object obj = _rs.getString(property); //snip return obj.toString(); }
public boolean setProperty(String property, Object value) throws
SQLException { //snip
_rs.updateObject(property, value);
_rs.updateRow();
//snip
}
So back to the example I had earlier involving the form needs "annualSalary" and the db requires a "salaryPerWeek." Imagine we did a retrieveAll and wanted to display back the results to the user and we were still stuck having to use the db column salaryPerWeek yet we needed to display annual salary ( salaryPerWeek * 52 ) to the user. Each iteration would end up calling the dao getProperty(String prop) listed above.
Sounds resonable. RowSet (it's not a resulset) is realy a list and my new example you mentioned makes it clearer.
I'm wondering how the DAOhelper would work? I'm guessing here- but would it work as another layer in between the BasicDAOImpl and the FormBeanDAO (ie StoreDAO)?
There is only one Concreate DAO in memory.
BaseDAOImpl implements BaseDAO interface. StoreDAO, would extend the BaseDAOImpl, thus in memory one DAO. DAO has to do all the hard work of geting the data to the bean, no mater how hard or easy.
<wrong>
</wrong>
So for example the DAOhelper might have a method:
DAOhelper extends BasicDAOImpl
public String getProperty(String property) throws SQLException { String result = null; Object obj = _rs.getString(property);
if ( property == Constants.ANNUAL_SALARY ) { result = SomeObject.calculateSalaryPerWeek( obj.toString() ); } else { result = super.getProperty( property ); } return result; }
and then a similar setProperty method overriding the base BasicDAOImpl's setProperty().
See above.
For each bean, you extend the BasicDAOImpl, for you concreate DAO helper.
I will drop the basicPortal module soon, and put up a bP module, that is list based and iBatis based, since people kind of get counfused by RowSet thing, but it's the same design. bP is in CVS already, just not released yet.
What I like about the above approach is that it keeps you original BasicDAOImpl nice and clean as a representation of the db columns.
BaseDAOImpl stores reusable parts that are common to all concreate DAO's thus name is Base.
The
Helper would be one of those sort-of-ugly things you have to add to deal with the situations where the presentation doesn't match the db.
geeting very close.
I haven't seen an implementation of the helper class so I'm not at all certain this is even remotely what you would do:) It just seems like it should work.
Look more at CVS bP.
.V
_______________________________________________ MVC-Programmers mailing list [EMAIL PROTECTED] http://www.basebeans.net:8080/mailman/listinfo/mvc-programmers
