Menu
▾
▴
Fwd: RE: [Springframework-developer] A few questions
|
From: Lars F. <lar...@gm...> - 2003-08-26 15:50:39
|
Thanks Jürgen,
your company must be very happy having such an outstanding developer
and personality.
Spring really seems to be a very complete framework. What makes it
hard for beginners is the amount of possibilities and configuration
options.
This kind of valuable information you provide to the list should be
put on the WIKI. What do you think about this ?
Lars
> > 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="exampleDataAccessObject"
> > class="example.ExampleDataAccessObject">
> > <property name="sessionFactory"><ref
> > bean="mySessionFactory"/></property>
> > <property name="exampleParam"><value>someValue</value></property>
> > </bean>
> >
> > 1.) When do I need the part defining (do I need it at all?)
> >
> > <bean id="exampleBusinessObject"
> > class="example.ExampleBusinessObject">
> > <property name="transactionManager"><ref
> > bean="myTransactionManager"/></property>
> > <property name="dataAccessObject"><ref
> > bean="exampleDataAccessObject"/></property>
> > <property
> > name="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
> > 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.
> > 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
> >
>
>
|
