You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Wesley Wannemacher <We...@doubleatrailer.com> on 2006/10/06 15:58:32 UTC
FRIDAY #1 JavaBeans/Model
Hello,
I'm exercising the 'Casual Friday' rule here to ask some general
questions. I apologize in advance if I break any list etiquette, but I
subscribed on Monday and have been waiting patiently for Friday so that
I can get these questions off my chest. Thanks!
I've been working on Java/JSP for a few years now and I recently decided
to try out struts (better late than never). In the past, I would
typically write a JDBC wrapper library to help me get to the database,
then write all of my code with little abstraction from SQL code. Being a
database guy as well, this made sense to me, and I could do quick easy
things like a 'QueryToTables' tag that would allow me to paste SQL code
right into a JSP and have the results of that query pasted nicely into
the output. For updates, I would build the form I needed (using my own
custom tags for input fields) and call into my JDBC wrapper to hit
stored procedures.
I picked up a copy of 'Struts Design and Programming: A Tutorial' and I
am learning the details of the libraries, but I've never written a
JavaBean (EJB or regular Bean). It seems that EJB isn't necessary, but
that regular JavaBeans are used heavily elsewhere. So, I figured I would
start trying to figure out smart JavaBean Design (I don't really want to
have to refactor/redesign all of my core classes later when I'm more
experienced). The problem I have though is that all the books I have
laying around seem only to refer to plain ol' JavaBeans as GUI
components. If I understand correctly, to make an object a JB, I really
only have to have getters/setters for the properties I want to expose,
but can I have other methods that do other stuff? What suggestions would
you give someone who has never written a JavaBean before that is going
to begin working from the ground up on a new project? I figured I would
use iBATIS for database persistence, so I've been reading about that as
well. I guess I'm just a bit paranoid about writing the 'middle layer'
between struts and the SQL code/server, so any advice on gotchas and/or
suggestions for struts-friendly 'middle layer' design would be much
appreciated.
-Wes
--
Wes Wannemacher
Double A Trailer Sales, Inc.
wesw@doubleatrailer.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: FRIDAY #1 JavaBeans/Model
Posted by Simon Chappell <si...@gmail.com>.
On 10/6/06, Wesley Wannemacher <We...@doubleatrailer.com> wrote:
> Hello,
>
> I'm exercising the 'Casual Friday' rule here to ask some general
> questions. I apologize in advance if I break any list etiquette, but I
> subscribed on Monday and have been waiting patiently for Friday so that
> I can get these questions off my chest. Thanks!
Some folks don't wait until Fridays! :-)
> I've been working on Java/JSP for a few years now and I recently decided
> to try out struts (better late than never). In the past, I would
> typically write a JDBC wrapper library to help me get to the database,
> then write all of my code with little abstraction from SQL code. Being a
> database guy as well, this made sense to me, and I could do quick easy
> things like a 'QueryToTables' tag that would allow me to paste SQL code
> right into a JSP and have the results of that query pasted nicely into
> the output. For updates, I would build the form I needed (using my own
> custom tags for input fields) and call into my JDBC wrapper to hit
> stored procedures.
Err, yes. Quite so. I'm not a database kind of guy, so I'll trust that's good.
> I picked up a copy of 'Struts Design and Programming: A Tutorial' and I
> am learning the details of the libraries, but I've never written a
> JavaBean (EJB or regular Bean). It seems that EJB isn't necessary, but
> that regular JavaBeans are used heavily elsewhere. So, I figured I would
EJBs are not necessary for Struts apps. I led a team that produced a
pretty good sized Struts app that didn't even come close to using an
EJB.
> start trying to figure out smart JavaBean Design (I don't really want to
> have to refactor/redesign all of my core classes later when I'm more
> experienced). The problem I have though is that all the books I have
> laying around seem only to refer to plain ol' JavaBeans as GUI
> components. If I understand correctly, to make an object a JB, I really
> only have to have getters/setters for the properties I want to expose,
> but can I have other methods that do other stuff? What suggestions would
> you give someone who has never written a JavaBean before that is going
> to begin working from the ground up on a new project? I figured I would
Now, JavaBeans are just very structured value objects. All their
attributes are exposed through getters and setters as you observed.
The trick with JavaBeans is to let them be single-purpose and don't
try to mix in a few extras here and there. Use them for transporting
data and create other business logic objects to handle the "doing
stuff". There'll be tears before bedtime if you forget this basic
rule.
> use iBATIS for database persistence, so I've been reading about that as
> well. I guess I'm just a bit paranoid about writing the 'middle layer'
> between struts and the SQL code/server, so any advice on gotchas and/or
> suggestions for struts-friendly 'middle layer' design would be much
> appreciated.
The next thing to do is to work hard to keep the view/controller layer
distinct from the model. On my apps, I like to have a static class
called API (really!) that acts as the API into the entire business
back end. Each behaviour that an Action might want to call is behind a
method on the API. Calls into the API pass in a Request object and
receive back a Reply object. This helps keep ActionForms out of the
model.
The next thing I would do (actually did) would be to create subsystems
within the model to handle the different kind of activities that the
system is going to perform. Going to store data? Have a persistence
subsystem. Going to print stuff? Have a print subsystem. Going to
communicate with devices? Have a device subsystem. You get the
picture.
I could go on a while, but that'll get you started.
Simon
--
simonpeter.org | simonpeter.com | techbook.info
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: FRIDAY #1 JavaBeans/Model
Posted by Larry Meadors <lm...@apache.org>.
The iBATIS in Action book has a really good sample application that
uses iBATIS and Struts. You can get the ebook now in from the MEAP
($22.50), but if you need the dead tree version, it won't be ready
until December:
- http://manning.com/begin/
If free is more your price range, Rick Reumann has some good examples, too:
- http://learntechnology.net/struts-spring-ibatis.do
The IIA version uses the iBATIS DAO and Rick's uses Spring for the DAO
layer. If you have never used Spring, spend 1/2 a day with it, and
you'll get it well enough to use it. It's worth it.
Larry
On 10/6/06, Wesley Wannemacher <We...@doubleatrailer.com> wrote:
> Hello,
>
> I'm exercising the 'Casual Friday' rule here to ask some general
> questions. I apologize in advance if I break any list etiquette, but I
> subscribed on Monday and have been waiting patiently for Friday so that
> I can get these questions off my chest. Thanks!
>
> I've been working on Java/JSP for a few years now and I recently decided
> to try out struts (better late than never). In the past, I would
> typically write a JDBC wrapper library to help me get to the database,
> then write all of my code with little abstraction from SQL code. Being a
> database guy as well, this made sense to me, and I could do quick easy
> things like a 'QueryToTables' tag that would allow me to paste SQL code
> right into a JSP and have the results of that query pasted nicely into
> the output. For updates, I would build the form I needed (using my own
> custom tags for input fields) and call into my JDBC wrapper to hit
> stored procedures.
>
> I picked up a copy of 'Struts Design and Programming: A Tutorial' and I
> am learning the details of the libraries, but I've never written a
> JavaBean (EJB or regular Bean). It seems that EJB isn't necessary, but
> that regular JavaBeans are used heavily elsewhere. So, I figured I would
> start trying to figure out smart JavaBean Design (I don't really want to
> have to refactor/redesign all of my core classes later when I'm more
> experienced). The problem I have though is that all the books I have
> laying around seem only to refer to plain ol' JavaBeans as GUI
> components. If I understand correctly, to make an object a JB, I really
> only have to have getters/setters for the properties I want to expose,
> but can I have other methods that do other stuff? What suggestions would
> you give someone who has never written a JavaBean before that is going
> to begin working from the ground up on a new project? I figured I would
> use iBATIS for database persistence, so I've been reading about that as
> well. I guess I'm just a bit paranoid about writing the 'middle layer'
> between struts and the SQL code/server, so any advice on gotchas and/or
> suggestions for struts-friendly 'middle layer' design would be much
> appreciated.
>
> -Wes
>
>
> --
> Wes Wannemacher
> Double A Trailer Sales, Inc.
> wesw@doubleatrailer.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
Re: FRIDAY #1 JavaBeans/Model
Posted by Mississippi John Hurt <jo...@gmail.com>.
I also like Ibatis better. To me, Ibatis is a better, more efficient, more
flexible, practical, transparent framework that gives you more control than
Hibernate.
On 10/6/06, Albert L. Sapp <as...@uiuc.edu> wrote:
>
> +1
>
> Al
>
> Larry Meadors wrote:
> > On 10/6/06, Ivo Limmen <iv...@gmail.com> wrote:
> >> iBATIS is only a small helper tool that will help you to map objects
> >> to the
> >> database. This requires a lot of code to write. If you use Hibernate
> >> you can
> >> write the mapping and generate your beans. Hibernate does however
> >> require
> >> some practice, it has a steep learning curve.
> >
> > I have to disagree. :-)
> >
> > Remember, iBATIS is *not* an ORM tool. It does not map your database
> > to your object model. IMO, this is a good thing: Database design and
> > object model design have different goals, so a tool that makes it
> > possible to more flexibly map data to objects adds a great deal of
> > value.
> >
> > Larry
> >
> > ---------------------------------------------------------------------
> > 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
>
>
Re: FRIDAY #1 JavaBeans/Model
Posted by "Albert L. Sapp" <as...@uiuc.edu>.
+1
Al
Larry Meadors wrote:
> On 10/6/06, Ivo Limmen <iv...@gmail.com> wrote:
>> iBATIS is only a small helper tool that will help you to map objects
>> to the
>> database. This requires a lot of code to write. If you use Hibernate
>> you can
>> write the mapping and generate your beans. Hibernate does however
>> require
>> some practice, it has a steep learning curve.
>
> I have to disagree. :-)
>
> Remember, iBATIS is *not* an ORM tool. It does not map your database
> to your object model. IMO, this is a good thing: Database design and
> object model design have different goals, so a tool that makes it
> possible to more flexibly map data to objects adds a great deal of
> value.
>
> Larry
>
> ---------------------------------------------------------------------
> 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
Re: FRIDAY #1 JavaBeans/Model
Posted by Larry Meadors <lm...@apache.org>.
On 10/6/06, Ivo Limmen <iv...@gmail.com> wrote:
> iBATIS is only a small helper tool that will help you to map objects to the
> database. This requires a lot of code to write. If you use Hibernate you can
> write the mapping and generate your beans. Hibernate does however require
> some practice, it has a steep learning curve.
I have to disagree. :-)
Remember, iBATIS is *not* an ORM tool. It does not map your database
to your object model. IMO, this is a good thing: Database design and
object model design have different goals, so a tool that makes it
possible to more flexibly map data to objects adds a great deal of
value.
Larry
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: FRIDAY #1 JavaBeans/Model
Posted by Ivo Limmen <iv...@gmail.com>.
Hi Wesley,
Our company has just decided to standardize on Struts (1.3.5 currently) and
for database mapping for Hibernate 3 and up.Struts is not limited to a
specific database mapping tool, so you will need to make a selection. iBATIS
is only a small helper tool that will help you to map objects to the
database. This requires a lot of code to write. If you use Hibernate you can
write the mapping and generate your beans. Hibernate does however require
some practice, it has a steep learning curve.
See http://www.hibernate.org for more information.
Hope you figure it out...
On 10/6/06, Wesley Wannemacher <We...@doubleatrailer.com> wrote:
>
> Hello,
>
> I'm exercising the 'Casual Friday' rule here to ask some general
> questions. I apologize in advance if I break any list etiquette, but I
> subscribed on Monday and have been waiting patiently for Friday so that
> I can get these questions off my chest. Thanks!
>
> I've been working on Java/JSP for a few years now and I recently decided
> to try out struts (better late than never). In the past, I would
> typically write a JDBC wrapper library to help me get to the database,
> then write all of my code with little abstraction from SQL code. Being a
> database guy as well, this made sense to me, and I could do quick easy
> things like a 'QueryToTables' tag that would allow me to paste SQL code
> right into a JSP and have the results of that query pasted nicely into
> the output. For updates, I would build the form I needed (using my own
> custom tags for input fields) and call into my JDBC wrapper to hit
> stored procedures.
>
> I picked up a copy of 'Struts Design and Programming: A Tutorial' and I
> am learning the details of the libraries, but I've never written a
> JavaBean (EJB or regular Bean). It seems that EJB isn't necessary, but
> that regular JavaBeans are used heavily elsewhere. So, I figured I would
> start trying to figure out smart JavaBean Design (I don't really want to
> have to refactor/redesign all of my core classes later when I'm more
> experienced). The problem I have though is that all the books I have
> laying around seem only to refer to plain ol' JavaBeans as GUI
> components. If I understand correctly, to make an object a JB, I really
> only have to have getters/setters for the properties I want to expose,
> but can I have other methods that do other stuff? What suggestions would
> you give someone who has never written a JavaBean before that is going
> to begin working from the ground up on a new project? I figured I would
> use iBATIS for database persistence, so I've been reading about that as
> well. I guess I'm just a bit paranoid about writing the 'middle layer'
> between struts and the SQL code/server, so any advice on gotchas and/or
> suggestions for struts-friendly 'middle layer' design would be much
> appreciated.
>
> -Wes
>
>
> --
> Wes Wannemacher
> Double A Trailer Sales, Inc.
> wesw@doubleatrailer.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: FRIDAY #1 JavaBeans/Model
Posted by "Albert L. Sapp" <as...@uiuc.edu>.
Wesley,
From personal experience, I know where you are coming from. I started
out knowing even less about this than you. I will say though that it
was fairly easy and quick to pick up both Struts and iBatis. The design
standards were handed down from a project leader long gone before we
even rolled out even the first basic modules, so I hope you have a
little more flexibility to set your own. We use plain old java objects
for our transfer objects between all 3 parts of the MVC for our
application. JSP for our view, Struts for our controller and iBatis for
our model. Our current design could probably benefit from a rethink,
but we have not rolled out all of version 1 yet.
We don't do much more beyond standard getters/setters in the POJOs.
Some validation is done in the Struts validate and some in the actions
before everything is turned over to our module managers which turn
things over to the appropriate DAO and sql maps. Like I said, this is
what I was handed and I don't know if we went overboard in abstraction
or not. Just my 2 cents. Enjoy the ride.
Al
Wesley Wannemacher wrote:
> Hello,
>
> I'm exercising the 'Casual Friday' rule here to ask some general
> questions. I apologize in advance if I break any list etiquette, but I
> subscribed on Monday and have been waiting patiently for Friday so that
> I can get these questions off my chest. Thanks!
>
> I've been working on Java/JSP for a few years now and I recently decided
> to try out struts (better late than never). In the past, I would
> typically write a JDBC wrapper library to help me get to the database,
> then write all of my code with little abstraction from SQL code. Being a
> database guy as well, this made sense to me, and I could do quick easy
> things like a 'QueryToTables' tag that would allow me to paste SQL code
> right into a JSP and have the results of that query pasted nicely into
> the output. For updates, I would build the form I needed (using my own
> custom tags for input fields) and call into my JDBC wrapper to hit
> stored procedures.
>
> I picked up a copy of 'Struts Design and Programming: A Tutorial' and I
> am learning the details of the libraries, but I've never written a
> JavaBean (EJB or regular Bean). It seems that EJB isn't necessary, but
> that regular JavaBeans are used heavily elsewhere. So, I figured I would
> start trying to figure out smart JavaBean Design (I don't really want to
> have to refactor/redesign all of my core classes later when I'm more
> experienced). The problem I have though is that all the books I have
> laying around seem only to refer to plain ol' JavaBeans as GUI
> components. If I understand correctly, to make an object a JB, I really
> only have to have getters/setters for the properties I want to expose,
> but can I have other methods that do other stuff? What suggestions would
> you give someone who has never written a JavaBean before that is going
> to begin working from the ground up on a new project? I figured I would
> use iBATIS for database persistence, so I've been reading about that as
> well. I guess I'm just a bit paranoid about writing the 'middle layer'
> between struts and the SQL code/server, so any advice on gotchas and/or
> suggestions for struts-friendly 'middle layer' design would be much
> appreciated.
>
> -Wes
>
>
> --
> Wes Wannemacher
> Double A Trailer Sales, Inc.
> wesw@doubleatrailer.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
AW: FRIDAY #1 JavaBeans/Model
Posted by Martin Kindler <ki...@arcor.de>.
I am not really a Java Guru, but have made the experience that in effect the
name "Bean" is - in the context of Struts-based Webapps - really nothing
more than a POJO following the naming conventions of JavaBeans for
getters/setters.
With respect to the "middle layer", it really pays off to separate "model",
"view", and "controller" and possibly separate the persistency layer from
the model as well.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org