[OT] Re: Preparable or interceptors - is there a better mailing list than this ? some thing for total newbies.

[Dave Newton <ne...@yahoo.com>]

--- Mansour <ma...@yahoo.com> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [OT] Re: Preparable or interceptors - is there a better mailing list than this ? some thing for total newbies.

[Mansour <ma...@yahoo.com>]

Dave Newton wrote:
> --- Mansour <ma...@yahoo.com> 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.
>
>   

That exactly what i did.

> Then in your action:
>
> public String execute() throws Exception {
>     // ...
>     getEmployee().save();
>     // ...
> }
>
>   

That what I am looking for, but with out the extra fat.

In jsf there's a view, a backing bean, and POJO. However, the backing 
bean holds the POJO and controls it base on user input. In struts2, I 
have to write a persistence code, so that the operations on the POJO can 
be performed in a similar way.  What is the way around writing these 
extra classes which will involve modifying my existing code ?


>> 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.
>   

This is what I am trying to avoid writing at this point.
I need only action and POJO.

> - 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org