--- Mansour <[EMAIL PROTECTED]> wrote:
> I was looking to encapsulate all the behavior of the
> account in an account object. So the object updates
> its self.
There's no reason you *can't* do that, but the
architecture overlords will not be pleased.
S2 doesn't care about what else is in the object in
question, as long as it exposes appropriate get/set
methods for the form values you're interested in.
So if you had an object that looked like:
public class Employee {
private String fname; // ...and get/set
private String lname; // ...and get/set
public void save() {
// Does DB stuff...
}
}
you could still use:
<s:textfield name="employee.fname"/>
in your JSP.
Then in your action:
public String execute() throws Exception {
// ...
getEmployee().save();
// ...
}
> Again, accountService is another class. So I have to
> split the attr form the behavior of each object in
> two classes. right?
You probably *should* but you don't have to.
> And I have to change the bussiness logic
> (AccountService) to suit this design.
Depends on how you implement AccountService, I guess.
A lot of people using S2 take advantage of Spring and
its support for several persistence paradigms[1].
While I prefer iBatis or Hibernate, JDBC is another
Spring built-in option.
As an example, a Hibernate version of an Employee CRUD
action might consist of (at least) the following:
- An S2 Action: tells application where to go and why.
- An IEmployeeService: wraps up persistence
functionality.
- An Employee object: very simply POJO.
In turn, the IEmployeeService implementation might
contain an IEmployeeDao. Since my most recent project
have been Hibernate-based I use a modified
HibernateTools template to generate the DAO and its
interface.
I'll tell my IEmployeeService impl to save the current
employee:
getEmployeeService().saveOrUpdate(getEmployee());
My Hibernate impl of IEmployeeService.saveOrUpdate()
will look more or less like:
Session session = getSessionFactory().openSession();
Transaction tx = session.beginTransaction();
session.saveOrUpdate(employee);
tx.commit();
session.close();
Your JDBC impl of IEmployeeService.saveOrUpdate()
might look like (pseudo-code):
if (employee.id == null) {
// Build SQL update string.
} else {
// Build SQL insert string.
}
That's what you're currently putting in the Employee
object.
Why don't I think that's a good idea? It tightly
couples your data to how you deal with your data.
Isn't that what OOP is for? In theory, yes. In
practice, it just doesn't work out that well,
particularly in Java.
Now, you could put persistence stuff in your object
via an interface; I'd be less irritated with that, so
Employee would have an IEmployeeService in it, which
could then be called (internally) by Employee. Meh.
Again, for simple use-cases, I don't think it matters.
Java architect cowboys get all bent-out-of-shape when
they see code like that, but... let's face it, if it's
never going to change, or you're not doing "real"
enterprise work, or (insert several other use-cases
where I don't care) I just don't think it matters.
d.
[1] *ding ding ding* I got to say paradigm today, and
it isn't even noon yet.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
