struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mansour <mansou...@yahoo.com>
Subject Re: [OT] Re: Preparable or interceptors - is there a better mailing list than this ? some thing for total newbies.
Date Sun, 15 Apr 2007 15:48:05 GMT
Dave Newton wrote:
> --- Mansour <mansour77@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


Mime
View raw message