Jesse
You're correct. I'm not sure how complex Paul's application is, but indeed,
separating it's logic into such a layers is a good idea. Paul asked about
examples - the best I know is RedHat's WAF. There is a powerful persistence
layer, handling objects creation and manipulation, and domain objec
I would compare this problem with the EJB's... (even if I do not really like
the EJB's).
The DAO corresponds to the Entity-Bean. It should govern the atomar life-cycle
of the single Business-Object.
Then you have the Session-Bean which implements the use-case-logic. This class
contains the logic
On Apr 15, 2004, at 1:13 PM, Paul Barry wrote:
I doesn't seem like this logic belongs in the DAO either, because if
you don't want that kind of logic mixed in with code to get the data
out of the database. Does it belong in the business objects, maybe by
expanding the Widget object like this?
Hi
I'm not sure if this follows the 'best practices' (for me it do) and what
kind of RDBMS you're using, but the best place for such a logic is a
database itself. Using stored procedures, you can code such a checking and
validation on the table level, and avoid code overhead.
Sergiusz
--
I'm not sure about the best practice,but I would use
an application specific Controller
(Controller/Mediator pattern)class to perform the
logic. I use a controller class for all related
operations in use case(s) /subsystem.It controls all
interactions between the UI and business layers.
In my Actio
We have been using http://ibatis.com/ for both sql mapping and it DAO
framework. Might be worth it to check it out. It has good examples of
both DAO's and Service layers.
Nathan
On Apr 15, 2004, at 11:13 AM, Paul Barry wrote:
I have a question about business logic. The best way I can thin
One option is to use "service" objects that sit between the DAOs and the
Actions. Following your example, one service class might look something like
this:
public class WidgetService {
public void delete(int id) {
WidgetDAO w = new WidgetDAO();
try {
Hi Paul,
I would implement "BusinessRule"s (make that "UseCase"s?) objects that
encapsulate the BL behind your app. Then, in an "upper" layer, I would
implement "TransactionalOperation"s objects that define a transactional
operation (thus encapsulating the begin and the end of your
transaction), w
Take at look at:
http://www.corej2eepatterns.com/Patterns2ndEd/PatternRelationships.htm
More specifically the Application Service pattern
http://www.corej2eepatterns.com/Patterns2ndEd/ApplicationService.htm
BTW, its a great book!
robert
> -Original Message-
> From: Paul Barry [mailto:[E
9 matches
Mail list logo
