struts using jdbc

[ros]

Hello,

I am new to Struts. Have worked on a few tutorials and have attempted
a few simple exercises. Currently I am working on an exercise where I
have to access a MySQL database from the main jsp page ( which asks
the user for name) and display the data related to the user.

I would be really thankful if somebody pointed me to some online
resource where I could study more about this stuff and attempt the
exercise. Tutorial etc.

Cheers
ros

 

[Lew]

Hello,

I am new to Struts. Have worked on a few tutorials and have attempted
a few simple exercises. Currently I am working on an exercise where I
have to access a MySQL database from the main jsp page ( which asks
the user for name) and display the data related to the user.

I would be really thankful if somebody pointed me to some online
resource where I could study more about this stuff and attempt the
exercise. Tutorial etc.

Write a class, or package of classes, that contain the JDBC calls that create
the connection, prepare the SQL statement, execute the statement and retrieve
the results. That layer or class will translate the ResultSet or other return
values into objects that the rest of the application can use. (This is what
frameworks like Hibernate do.)

In your Action class create a data access object (DAO) of this class or one of
the package types, (Interfaces are best for the compile-time type.) Use that
instance to execute your data operations.

There are JDBC tutorials and other documentation amply available on the web.
GIYF.

 

[ros]

Write a class, or package of classes, that contain the JDBC calls that create
the connection, prepare the SQL statement, execute the statement and retrieve
the results. That layer or class will translate the ResultSet or other return
values into objects that the rest of the application can use. (This is what
frameworks like Hibernate do.)

In your Action class create a data access object (DAO) of this class or one of
the package types, (Interfaces are best for the compile-time type.) Use that
instance to execute your data operations.

There are JDBC tutorials and other documentation amply available on the web.
GIYF.

Thanks for the hight-level explanation Lew. Trust me, it helps a lot.
I'll get working on the exercise and shall post here the problems (I
know there will be!) that arise.

Thanks again.
Ros

 

[Richard Senior]

In Struts, the way you would generally do this would be:

1. JSP submits to a Struts action, passing validated username via form
2. Struts action assembles data from the database based on the username
3. Data put into request scope attribute - request.setAttribute(...)
4. Action forwards to the JSP that will display the data
5. JSP "view" displays the data put in the request

....
But then, for anything more than a trivial application, you should think
about separating your data access code from your action classes.

Having data access code in actions couples your choice of
view/controller framework, i.e. Struts, to your choice of data access,
i.e. JDBC/DAO. Delegating the data access to another layer of code makes
it easier to change your DAO implementation, e.g. to Hibernate, later on
and promotes re-use of your data access code.

So, in your action classes, instead of code like this ...

try {
MyDAO dao = new MyDAO(connection);
Person p = dao.fetch(id);
...
}
catch (java.sql.SQLException e) {
...
}

.... you have code more like this.

try {
Person p = MyDelegate.getPerson(id);
...
}
catch (com.mycompany.NotFoundException e) {
...
}

.... which is business-focussed rather than data access focussed and
doesn't change if you move to something like Hibernate or EJB.

 

[Lew]

Having data access code in actions couples your choice of
view/controller framework, i.e. Struts, to your choice of data access,
i.e. JDBC/DAO. Delegating the data access to another layer of code makes
it easier to change your DAO implementation, e.g. to Hibernate, later on
and promotes re-use of your data access code.

JDBC/DAO classes are arguably a better choice than Hibernate.

You bandy about terms like "promotes re-use of your data access code" as if
that were actually possible or beneficial. Data access code is tightly tied,
and inevitably so, to the data model for an application and the logic
performed on the data. This militates against re-use of data stuff, although
I do reuse abstract classes that handle connecting, disconnecting and the
like. But then, I wrote those classes, so they don't suffer the weaknesses an
O-R Moreau creates.

As for switching from an RDBMS direct access to Hibernate, bleah! That's for
people who don't get set algebra and the power of SQL. Every time I've used
one of those "O-R" frameworks I've spent more time and effort fighting its
limitations that I would have done using JDBC and SQL. Having done it both
ways, I feel secure in this assessment.

Object views recapitulate the flaws of the network model database, which lost
to the relational model a couple of decades ago for good reason. (I've worked
on network model databases, too.) Hibernate is a waste of time and energy and
locks you away from the value of SQL.

I change databases on the back end all the time, but that's apples to apples.
I would not trade the power of an RDBMS for the crippling bloat of a
Hibernatish framework.

 

[Richard Senior]

JDBC/DAO classes are arguably a better choice than Hibernate.

I don't disagree. I wasn't in any way recommending Hibernate. But
coupling your data access mechanism of choice into Struts is bad
practice on larger applications.

To quote the Struts HOWTO "How To Access a Database"
http://struts.apache.org/1.3.8/faqs/db-howto.html ...

"Ideally, all the database access code should be encapsulated behind the
business API classes, so the framework doesn't know what persistent
layer you are using (or even if there is a persistence layer). It just
passes a key or search String and gets back a bean or collection of
beans. This lets you use the same business API classes in other
environments, and also to run unit tests against your business API
outside of a web environment."

You bandy about terms like "promotes re-use of your data access code" as
if that were actually possible or beneficial. Data access code is
tightly tied, and inevitably so, to the data model for an application
and the logic performed on the data.

Of course re-use of data access code is possible and beneficial! The
quote above alludes to the same. It's basic programming good practice:

* Put calls to DAOs into a Business Delegate layer and call the
delegate rather than duplicating code and database level exception
handling across action classes.

* Make calls to the same API in other applications.

Is that not re-use?

And yes, of course data access code is tightly coupled to the data model
and perhaps even the database. That's precisely why it should be
accessed via a clean business interface - so that your application isn't
coupled in the same way!

 

[Lew]

I don't disagree. I wasn't in any way recommending Hibernate. But
coupling your data access mechanism of choice into Struts is bad
practice on larger applications.

I agree with pretty much everything you said in your post.

....

Of course re-use of data access code is possible and beneficial! The
quote above alludes to the same. It's basic programming good practice:

* Put calls to DAOs into a Business Delegate layer and call the
delegate rather than duplicating code and database level exception
handling across action classes.

* Make calls to the same API in other applications.

Is that not re-use?

I don't reuse all of the same API in other applications. I copy the same base
classes and re-extend to application-specific logic and entities. So it is
re-use and it isn't. Because each application winds up with different data
and logic, I can't reuse everything, and what I do resuse will just be the
interfaces and abstract classes.

So yes, it's reuse at one level. I should have specified that I meant that
the concrete implementations may not be reusable.

And yes, of course data access code is tightly coupled to the data model
and perhaps even the database. That's precisely why it should be
accessed via a clean business interface - so that your application isn't
coupled in the same way!

Yes - I practice this. I believe in isolating the data layer more than I do
in reusing it.

But the entities, the facts of the data model, perforce are present in every
layer, front to back. If you need someone's hair color, that'll be reflected
in the input forms and surface validation, the business logic and the data
structures. An app that doesn't care about hair color will not be able to
reuse those factors.

Likewise the logic - if you care about changing hair color your object model
and behaviors will be very different from those of an app that tracks payroll
deductions.

The reuse is at the abstract layer; the devil is in the implementation details.