Rick Reumann wrote:
On Thu, 13 Mar 2003 06:22:58 -0500
Vic Cekvenich <[EMAIL PROTECTED]> wrote:
Also, a bean should not do persistence, but should delegate. So I create a "helper" object, a DAOImplementation. ( a DAO also has a base). One thing is obvoice, a baseBean needs to CRUD, so it makes sense to baseBean { public void save() { DAO.update(); }}
I love the OO approach to your code, I'm just still very confused about how a simple implementation of a BaseBean would work in calling a DAO to save itself? In other words, what gets passed to the DAO from the BaseBean implementation to do the CRUD?
For example in a case where you had:
EmployeeFormBean extends BaseBean
I would take it EmployeeForBean would need to hold user fields such as firstName, lastName, address, etc with appropriate getter and setters. How do these fields then get passed to your DAO for the CRUD operations?
A bean has getters and setters as you said, and it gets and sets them to a list (of a maps), where a list is a property of the Bean!
So that is why I say list/collection backed bean.
So no DAO here, and simple to "fake" for a prototype, even multi row.
Then on bean.save(){ myDAO.update(localList); } That is the beans part! It delegates, so no magic or secret.
3rd, in DAO update (list l) { // code to intalize a transaction // code to iterate the list // code to update each row //code to commit, release // Suprisingly, this code can be generic/reusable via OO }
Yes, your implemenation is great. I will walk you over the phone.
hth, V
Thanks,
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
