Thread: RE: [Springframework-developer] A few questions

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

ad 1)

A data access object is supposed to be concerned just with actual data =
access operations, it shouldn't care about transactions or being part of =
a larger unit-of-work. It will mainly offer methods like "loadProduct", =
"findProducts", "storeOrder", "deleteOrder". Invoked directly, those =
methods will simply execute non-transactional, i.e. without =
transactional guarantees.

A business object is supposed to implement business operations, i.e. the =
units-of-work that a web controller or remote client needs to trigger. =
This can be simple delegations to DAO methods, or more complex business =
logic like creating an Order object, filling it with customer data and =
line items, and invoking the DAO's storeOrder afterwards.

Such a business object will typically demarcate transactions, i.e. most =
of its methods will need to execute within a transaction. It can =
demarcate those transactions via TransactionTemplate, that's why it =
receives a transaction manager reference in the skeleton. An alternative =
is an AOP TransactionInterceptor that proxies the business object =
itself.

So a data access object should get a resource factory like a JDBC =
DataSource or a Hibernate SessionFactory but not a transaction manager. =
With a business object, it's exactly the other way round. A business =
object should talk to its DAOs through interfaces that are agnostic of =
the actual persistence strategy, to be able to switch e.g. from JDBC to =
Hibernate seamlessly.

Compare a business object with a Stateless Session Bean that serves as =
business facade, just much more lightweight. After all, these are just =
patterns: For simple use cases, you might keep all of this in one =
object, not separating between business and data access operations.

2)

A DAO that just uses HibernateTemplate does not guarantee transactional =
safety. You need to some kind of transaction demarcation for this. As =
outlined above, this typically happens in business facades that delegate =
to the DAOs. You could also choose to use a TransactionTemplate in your =
DAO, preferably in facade methods that delegate to the actual data =
access methods. Or proxy your DAO with an AOP TransactionInterceptor.

3)

There is indeed a strong difference between Controller and =
MultiActionController. Controller is intended for classes that implement =
one single request handling use case each, e.g. a =
ShowProductListController and a ShowProductDetailsController. =
Controller's sole method is "handleRequest(request,response").

MultiActionController on the other hand allows to implement multiple use =
cases in one class, via multiple request handling methods like =
"showProductList(request,response)" and =
"showProductDetails(request,response)". Which method gets invoked is =
decided via a respective MethodNameResolver strategy, e.g. according to =
a request parameter or an explicit mapping. This is convenient for =
multiple small use cases to avoid an excessive number of controller =
classes.

Note that Spring separates roles stricter than WebWork. In WebWork, an =
Action is controller, command/form, and model in one object: It gets =
instantiated, populated, executed, and passed to the view. This is not =
really clean, as a view doesn't need to see the controller methods or =
the original command properties: A view just needs the pure model that =
it should render.

A Spring Controller is just a controller in the sense that it determines =
the processing workflow, that's why it can be a reusable singleton. A =
Spring command object is just a holder of command properties, =
instantiated per request. A Spring model is a map of named attributes =
that are provided to views, which may include a form object and/or =
reference data. Such a model does not have to include anything that a =
view doesn't need to see.

In terms of convenience base classes, you can choose between:
- a pure controller that acts as dispatched replacement of a servlet;
- a command controller that instantiates a command object, populates it =
with request parameters, and decides how to proceed then;
- a form controller that works similar to a command controller but =
applies a form editing workflow with form view and submit view;
- a wizard form controller that applies a form workflow with multiple =
pages.

So if you're used to the WebWork or classic Servlet style, simply stay =
with Controller and its convenience subclasses like =
AbstractCommandController or SimpleFormController. On the other hand, =
people coming from Struts 1.1 might prefer MultiActionController as they =
know a similar concept: Struts' DispatchAction.

Juergen

-----Original Message-----
From: Lars Fischer [mailto:lar...@gm...]
Sent: Tuesday, August 26, 2003 12:00 PM
To: spr...@li...
Subject: [Springframework-developer] A few questions

Finally I've managed to get the whole thing working with Hibernate and
WebLogic.

There are still a few newbie questions left:

In applicationContext.xml from the Hibernate skeleton I've defined this
part:

<bean id=3D"exampleDataAccessObject" =
class=3D"example.ExampleDataAccessObject">
  <property name=3D"sessionFactory"><ref =
bean=3D"mySessionFactory"/></property>
  <property name=3D"exampleParam"><value>someValue</value></property>
</bean>

1.) When do I need the part defining (do I need it at all?)

<bean id=3D"exampleBusinessObject" =
class=3D"example.ExampleBusinessObject">
  <property name=3D"transactionManager"><ref
bean=3D"myTransactionManager"/></property>
  <property name=3D"dataAccessObject"><ref
bean=3D"exampleDataAccessObject"/></property>
  <property =
name=3D"exampleParam"><value>someOtherValue</value></property>
</bean>

2.) In my DAO implementation I use HibernateTemplate. I assume that =
those
methods
are transaction safe with only the first part =
("exampleDataAccessObject")
defined (?).

3.) Spring provides a "Controller" and a "MultiActionController". For =
sure
there are lots=20
of architectural reasons for providing both. But wouldn't it be easier =
just
to provide one
kind of controller ? E.g. in WebWork 1 you can make a class ActionAware,
SessionAware, etc.=20
which is very easy to understand (when to use what even without
documentation).

Thanks again
Lars

-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click =
here:http://www.vmware.com/wl/offer/358/0
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer