You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Ric Searle <ri...@dialogue.co.uk> on 2002/04/11 12:39:41 UTC
Business Logic Javabeans
Apologies for the somewhat newbie-esque nature of this post, but I hope
you can clear up some confusion:
I'm developing my first struts application. In theory it's very simple
(at least, I could write in in no time in perl!). The key elements are:
- User creation / login / session tracking
- Logged in user can edit a tree-like structure stored in a mySQL
database.
I'm comfortable(ish) with the role of the controller servlet, and the
presentation JSP custom tags all look easy to use. I can even cope with
form beans to validate and pass around form submission data. My
confusion is in how to structure the business-logic side of the
application.
I *think* that my action servlets should use a "business-logic
javabean", rather than doing any database manipulation themselves. Here
I am struggling with the concept of a javabean, since every tutorial I
come across talks about them in the context of GUI development.
Am I right in thinking that it's just a normal class that follows some
naming conventions? In which case, should I have a class which
represents a 'User' and a class that represents my 'Database', which has
an addUser(myUser) method? I imagine the Database class to be a
front-end to the SQL.
Any thoughts would be appreciated, particularly if I'm way off the mark!
Ric Searle
Web Application Developer
--
Dialogue Communications Ltd, Sheffield, UK
http://www.dialogue.co.uk
+44 (0) 114 221 0307
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Business Logic Javabeans
Posted by Sandeep Takhar <sa...@yahoo.com>.
I think this depends on the set-up that you have.
the pattern you are referring to is business-delegate
and that is exactly what it does -- delegates.
the book ejb design patterns talks about the pros and
cons.
for us -- it doesn't make a lot of sense.
Sandeep
--- Jay sissom <js...@toybox.uits.indiana.edu>
wrote:
> While I agree that all this work should be done
> during the action, the
> code that implements your business logic shouldn't
> be directly in the
> perform method of the action object. It should be
> in other objects that
> you call. This provides for re-use of the business
> logic and seperation
> between the UI (action objects, form objects, jsp,
> jsp tags) and your
> business logic. These other objects don't have to
> conform to the javabean
> spec if you don't want them to. Most of the time
> ours does not.
>
> I think that's what was said earlier, but I wanted
> to clarify a bit.
>
> This is my opinion only of course.
>
> Jay
>
> On Thu, 11 Apr 2002, Oliver Refle wrote:
>
> > Sorry what i forgot to say, the business logic i
> meant is
> > mainly checking database, adding database entries
> and so on,
> > not changing the values or building a value
> object. This should
> > be done in the action
> >
> > -----Original Message-----
> > From: Ric Searle [mailto:ric@dialogue.co.uk]
> > Sent: Thursday, April 11, 2002 12:40 PM
> > To: struts-user@jakarta.apache.org
> > Subject: Business Logic Javabeans
> >
> >
> > Apologies for the somewhat newbie-esque nature of
> this post, but I hope
> > you can clear up some confusion:
> >
> > I'm developing my first struts application. In
> theory it's very simple
> > (at least, I could write in in no time in perl!).
> The key elements are:
> >
> > - User creation / login / session tracking
> > - Logged in user can edit a tree-like structure
> stored in a mySQL
> > database.
> >
> > I'm comfortable(ish) with the role of the
> controller servlet, and the
> > presentation JSP custom tags all look easy to use.
> I can even cope with
> > form beans to validate and pass around form
> submission data. My
> > confusion is in how to structure the
> business-logic side of the
> > application.
> >
> > I *think* that my action servlets should use a
> "business-logic
> > javabean", rather than doing any database
> manipulation themselves. Here
> > I am struggling with the concept of a javabean,
> since every tutorial I
> > come across talks about them in the context of GUI
> development.
> >
> > Am I right in thinking that it's just a normal
> class that follows some
> > naming conventions? In which case, should I have
> a class which
> > represents a 'User' and a class that represents my
> 'Database', which has
> > an addUser(myUser) method? I imagine the Database
> class to be a
> > front-end to the SQL.
> >
> > Any thoughts would be appreciated, particularly if
> I'm way off the mark!
> >
> >
> > Ric Searle
> > Web Application Developer
> > --
> > Dialogue Communications Ltd, Sheffield, UK
> >
> > http://www.dialogue.co.uk
> > +44 (0) 114 221 0307
> >
> >
> > --
> > To unsubscribe, e-mail:
> >
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Business Logic Javabeans
Posted by Jay sissom <js...@toybox.uits.indiana.edu>.
While I agree that all this work should be done during the action, the
code that implements your business logic shouldn't be directly in the
perform method of the action object. It should be in other objects that
you call. This provides for re-use of the business logic and seperation
between the UI (action objects, form objects, jsp, jsp tags) and your
business logic. These other objects don't have to conform to the javabean
spec if you don't want them to. Most of the time ours does not.
I think that's what was said earlier, but I wanted to clarify a bit.
This is my opinion only of course.
Jay
On Thu, 11 Apr 2002, Oliver Refle wrote:
> Sorry what i forgot to say, the business logic i meant is
> mainly checking database, adding database entries and so on,
> not changing the values or building a value object. This should
> be done in the action
>
> -----Original Message-----
> From: Ric Searle [mailto:ric@dialogue.co.uk]
> Sent: Thursday, April 11, 2002 12:40 PM
> To: struts-user@jakarta.apache.org
> Subject: Business Logic Javabeans
>
>
> Apologies for the somewhat newbie-esque nature of this post, but I hope
> you can clear up some confusion:
>
> I'm developing my first struts application. In theory it's very simple
> (at least, I could write in in no time in perl!). The key elements are:
>
> - User creation / login / session tracking
> - Logged in user can edit a tree-like structure stored in a mySQL
> database.
>
> I'm comfortable(ish) with the role of the controller servlet, and the
> presentation JSP custom tags all look easy to use. I can even cope with
> form beans to validate and pass around form submission data. My
> confusion is in how to structure the business-logic side of the
> application.
>
> I *think* that my action servlets should use a "business-logic
> javabean", rather than doing any database manipulation themselves. Here
> I am struggling with the concept of a javabean, since every tutorial I
> come across talks about them in the context of GUI development.
>
> Am I right in thinking that it's just a normal class that follows some
> naming conventions? In which case, should I have a class which
> represents a 'User' and a class that represents my 'Database', which has
> an addUser(myUser) method? I imagine the Database class to be a
> front-end to the SQL.
>
> Any thoughts would be appreciated, particularly if I'm way off the mark!
>
>
> Ric Searle
> Web Application Developer
> --
> Dialogue Communications Ltd, Sheffield, UK
>
> http://www.dialogue.co.uk
> +44 (0) 114 221 0307
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Business Logic Javabeans
Posted by Oliver Refle <o....@gmx.de>.
Sorry what i forgot to say, the business logic i meant is
mainly checking database, adding database entries and so on,
not changing the values or building a value object. This should
be done in the action
-----Original Message-----
From: Ric Searle [mailto:ric@dialogue.co.uk]
Sent: Thursday, April 11, 2002 12:40 PM
To: struts-user@jakarta.apache.org
Subject: Business Logic Javabeans
Apologies for the somewhat newbie-esque nature of this post, but I hope
you can clear up some confusion:
I'm developing my first struts application. In theory it's very simple
(at least, I could write in in no time in perl!). The key elements are:
- User creation / login / session tracking
- Logged in user can edit a tree-like structure stored in a mySQL
database.
I'm comfortable(ish) with the role of the controller servlet, and the
presentation JSP custom tags all look easy to use. I can even cope with
form beans to validate and pass around form submission data. My
confusion is in how to structure the business-logic side of the
application.
I *think* that my action servlets should use a "business-logic
javabean", rather than doing any database manipulation themselves. Here
I am struggling with the concept of a javabean, since every tutorial I
come across talks about them in the context of GUI development.
Am I right in thinking that it's just a normal class that follows some
naming conventions? In which case, should I have a class which
represents a 'User' and a class that represents my 'Database', which has
an addUser(myUser) method? I imagine the Database class to be a
front-end to the SQL.
Any thoughts would be appreciated, particularly if I'm way off the mark!
Ric Searle
Web Application Developer
--
Dialogue Communications Ltd, Sheffield, UK
http://www.dialogue.co.uk
+44 (0) 114 221 0307
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Business Logic Javabeans
Posted by Oliver Refle <o....@gmx.de>.
The bean on the GUI has to follow naming conventions, but thats
not the bean used to perform the business logic.
For that bean means only an own java class to seperate the
business logic from the gui(action,jsp).
Partially you can prepare your data in the action classes, but
the normal business should be done in another class which
don't have to follow an conventions if you don't want to
use EJB'S
Oliver
-----Original Message-----
From: Ric Searle [mailto:ric@dialogue.co.uk]
Sent: Thursday, April 11, 2002 12:40 PM
To: struts-user@jakarta.apache.org
Subject: Business Logic Javabeans
Apologies for the somewhat newbie-esque nature of this post, but I hope
you can clear up some confusion:
I'm developing my first struts application. In theory it's very simple
(at least, I could write in in no time in perl!). The key elements are:
- User creation / login / session tracking
- Logged in user can edit a tree-like structure stored in a mySQL
database.
I'm comfortable(ish) with the role of the controller servlet, and the
presentation JSP custom tags all look easy to use. I can even cope with
form beans to validate and pass around form submission data. My
confusion is in how to structure the business-logic side of the
application.
I *think* that my action servlets should use a "business-logic
javabean", rather than doing any database manipulation themselves. Here
I am struggling with the concept of a javabean, since every tutorial I
come across talks about them in the context of GUI development.
Am I right in thinking that it's just a normal class that follows some
naming conventions? In which case, should I have a class which
represents a 'User' and a class that represents my 'Database', which has
an addUser(myUser) method? I imagine the Database class to be a
front-end to the SQL.
Any thoughts would be appreciated, particularly if I'm way off the mark!
Ric Searle
Web Application Developer
--
Dialogue Communications Ltd, Sheffield, UK
http://www.dialogue.co.uk
+44 (0) 114 221 0307
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>