If you want to do up a simple application that involves persisting data,
here is what you want to start out with (includes open source library
recommendations):
First you need to do RDD Analysis, which is Responsibility Driven
Design. That means, make a list of everything you want your
application to do, usually this is referred to as an FRD or MRD in some
circles (Functionality/Marketing Requirements Document). Note,
sometimes the requirements documentation is proceeded by Use Cases or a
narrative of how a user interacts with the application. Once you have
all your requirements listed, you, as a programmer, should start
grouping or assigning these requirements to hypothetical services or
layers. Remember it is good to have lots of layers (well, not more than
5 or 6 in most cases). Sometimes these steps are accompanied by
extensive FUDs (F***ed up diagrams) to help get your ideas down quickly
(including your site map of all the pages).
Once you have your requirements broken up to layers, start defining the
objects that will accomplish your application's goals. I usually lay
out my whole application in interfaces before actually ever creating an
Object. This will force you into the Bridge Pattern methodology along
with extensive uses of the Factory or Factory Method Pattern. This is
the key for pluggable design. You will need to think about things such
as how transactions will take place-- like what are the steps for
creating and validating a User. Usually these flows are taken from Use
Cases or from FUDs. Match each step with a service layer and an object
to take care of it.
Now for the gritty technical stuff.
Persistence:
If you have a RDBMS available to you, such as SQL Server or MySQL, then
the easiest route is OJB (don't let others tell you differently,
especially if you aren't a follower of Joe Celko, author of "SQL for
Smarties"). OJB is available at Jakarta's web site and works perfectly
with the concept of interfacing all of your business objects. The neat
thing is that OJB will take care of all the SQL stuff for you. Granted,
it will take a few days to get OJB setup, but the development process
goes VERY FAST once everything's setup.
Another option is storing data as XML. Don't learn XML unless your boss
wants you to or if you get a kick out of learning other people's syntax.
There are a few libraries available to you such as Digester, Castor, and
Betwixt. All three libraries will take care of automatically converting
your Java Objects into well formatted XML and visa versa. I recommend
Betwixt for the beginner because everything is VERY simple. It also
extends the Digester Libraries in reading XML and converting it to a
Java Object for use. If you want to go hog wild with lots of
customizability, then check out Castor (www.castor.org). I've used it
on a few projects and I'm quite happy with it.
The Fire Break
Now, back to layering... As per my original email, we would want to
isolate the persistence layer, so put in an intermediate service layer
that acts like a curtain. We can call this intermediate layer the Fire
Break. The Fire Break hides your persistence layer from Struts so if
you end up changing the persistence layer, you don't have to change any
of your controller or view level code. The Fire Break in itself can act
like a controller or container of services, not only for persisting
objects. You could write up a Fire Break so it operated like such:
FireBreak fireBreak = FireBreak.getInstance(servletContext);
PersistenceService pServ = fireBreak.getPersistenceService();
pServ.store(myEmployeeObject);
By looking at the code, we've hid the persistence implementation via
interfaces so to the Struts Action, we don't know if we are storing
myEmployeeObject as XML or in a DB, we just know it was stored. Of
course, you might want to setup some kind of transaction object where
you ask the PersistenceService for a transaction object to use, and then
do all of your persistence tasks, then commit them or roll them back to
assure the ACID properties.
NOTE: If you are doing up something fast and gritty, then feel free to
throw the persistence layer calls in your Struts Actions, I will show an
example below of how to do this with OJB.
Controller (Struts):
If you did your job correctly above, your code in the Action's execute()
method should be less than 20 lines, possibly 10 lines:
// example without firebreak
public ActionForward execute(Blah blah blah)
{
EmployeeForm empForm = (EmployeeForm) form;
try
{
PersistenceBroker pb = pbFactory.getPersistenceBroker();
Employee empObject = new EmployeeObject();
BeanUtils.copyProperties(empForm, empObject);
pb.store(empObject);
}
catch (Exception e)
{
// do exception handling
}
return mappings.findForward("success");
}
That's all there is to it if you have your EmployeeForm pre-validated
with the Validator libraries. One thing to note with this is that you
have defined your Employee Business Object as an interface (as described
in the beginning of this novel), so we can take advantage of the
BeanUtil Libraries in just copying data from your view object (your
EmployeeForm) to your model object (EmployeeObject) for persisting.
View:
If you had originally done up a site map, specifying all of your JSPs,
make sure that EVERY link on your site first goes to an action. So
instead of linking to viewEmployee.jsp, you link to viewEmployee.do.
This means that your intermediate Action at viewEmployee.do is going to
take care of calling up OJB or Betwixt or whatever to get the data you
need, set it as an Attribute of the HttpServletRequest, and then return
an ActionForward to your real viewEmployee.jsp.
This is true MVC because your view does nothing but output data. Struts
should take care of all the work. You can look at JSTL like Craig and I
recommended with will leave you with a bunch of <c:out> tags on your
page which again, just output the data fetched by the Struts Action.
Anyways, I think I went on for a little to long, but I hope you can find
some good info in the mess.
Jacob Hookom
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
