Re: Struts Business Logic :: Best Practices
> The question is, how will I do that? How can I hook up a command to > spring? Commons CoR ships with an object loader that uses the Commons Dispatcher to create a Catalog (or repository) of Commands. But that's not the only way to create a Catalog. You could also use Spring to load your Chains, and inject into the Chain, Commands, or Context whatever dependencies you need. Here's the sort of thing I do with Spring.NET and a C# port of CoR: Or, you might want to do is think of the Context as a Spring Bean. Add JavaBean properties to a base Context, and instantiate that through Spring, and populate from the ActionForm. HTH, Ted. On Thu, 31 Mar 2005 11:13:08 +0100, Marco Mistroni <[EMAIL PROTECTED]> wrote: > Hello Ted, > I have one additional question about Struts Chain , MailReader > etc.. > Suppose that I want to use Spring beans... > Currently, with Struts 1.1, my action are extending > DelegatingActionProxy because actions are meant to use those beans. > If I use Commons Chain, then what is currently in the action will be > abstracted by Command/Context, correct? > So from that it follows that I should be able to retrieve spring beans > From command. > The question is, how will I do that? How can I hook up a command to > spring? > > Thanks in advance for your reply, please post also to the list if you > think > It's valuable... > > Regards > marco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Business Logic :: Best Practices
On Fri, 11 Mar 2005 13:09:58 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > > [http://raibledesigns.com/page/rd?anchor=appfuse_refactorings_part_ii_spring] > > Matt refactored Appfuse "in Anger" for Spring and has never looked back :) > What does this mean? Was AppFuse for something else originally? Thanks! -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Business Logic :: Best Practices
Rod Johnson's progress is from the latter book to the former one. Spring is in the middle. On Fri, 11 Mar 2005 19:27:04 +0100, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > > > If anyone is actually interested in IoC containers, check out Rod > > Johnson's book, "J2EE Development without EJB". > > ok, bought... :-) > Expert One-on-One J2EE Development without EJB > > what about > Expert One-to-One J2EE Design and Development ? > > regards > Leon > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Business Logic :: Best Practices
> If anyone is actually interested in IoC containers, check out Rod > Johnson's book, "J2EE Development without EJB". ok, bought... :-) Expert One-on-One J2EE Development without EJB what about Expert One-to-One J2EE Design and Development ? regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Business Logic :: Best Practices
Well, a framework is a semi-complete application [Johnson]. A lightweight container is essentially an object factory, as you implied. Struts is more than a framework. It's also a container that manages the lifecycle of the objects created by the struts-config. You could, for example, use Spring to load the struts-config instead of the Distiller. Right now, I'm using Spring to load my CoR objects. But, hey, the business-end of the applications someone else writes might not need or want a container. :) It's not possible for me to say why someone else needs a container. :) I can say why my team uses a container for our business logic objects. So Why? Because we really, really like writing a handful of base objects to do 90% of the work and configuring them in XML. Of course, your mileage may vary. A lot of people decide not to use Struts because they don't want to do the XML config thing. In the application in front of me now, we have 13 base objects that we use to create 51 commands or chains. After lunch, I'll add another 20 commands for editing various database records, but I won't need to add a single new class. All I need are new elements in the Spring config to configure old base objects with new details, and the corresponding datebase statements in the iBATIS config. It's not unlike using Tiles to create pages, except we're creating chains of business logic. If anyone is actually interested in IoC containers, check out Rod Johnson's book, "J2EE Development without EJB". Another good reference is Matt Raible's WebLog. [http://raibledesigns.com/page/rd?anchor=appfuse_refactorings_part_ii_spring] Matt refactored Appfuse "in Anger" for Spring and has never looked back :) But, at this point, I think we begin to digress ... -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Business Logic :: Best Practices
Ted Husted wrote: As to business objects, the usual advice is to use Plain Old Java Objects (POJOs). The current MailReader example application is an excellent example of creating a set of interfaces to represent business logic, then instantiating a set of classes to implement the business logic. The MailReader uses a Struts PlugIn to create the business logic beans in application scope. Another good approach is to use Spring to create your business objects. Here, you might use a PlugIn to create the Spring instance in application scope, and then call the Spring instance to create everything else. Of course, my favorite way to manage business objects now is as a Chain of Responsbility. But, to get started, you probably want to use plain old business beans, as the MailReader does. All this is to say, option 2. The Actions call the business beans, and the beans do all the heavy lifiting. (Actions shouldn't know *how* to do things, just who to ask to get things done.) The iBATIS DAO layer is cool, but if you don't need a switchable DAO, you can do the same thing using your own interfaces. Of course, my favorite way to do business logic now is using the Chain of Responsiblity. But, that's a bit bleeding edge right now :) -Ted. Hello Ted and concerned developers: I just like to make this piece-meal update on how we use commons-chain and hope to get some feedback from gurus out there. 1) I modify chain CatalogBase and ChainBase to turn CoR Catalog, Command, Filter, and Chain into POJO configurable using IoC. This will avoid an issue that Vic said about the Rich Client. 2) Extending the naming approach of Agility, bean references are all in names, including the DTO to keep DO and UI objects consistent. 3) All component services are done with chain Command. I am waiting for some "de-facto" standard of having conditional chain. Have you and struts committers set down the best way to do it? BaTien DBGROUPS On Fri, 11 Mar 2005 14:57:51 +0530, karthikeyan balasubramanian <[EMAIL PROTECTED]> wrote: Hi all, Struts DB Access Best Practices thread gave me great insight on how I should proceed with db operations. I have one more question. Where do you keep your business logic code. Right now I am thinking to use 1. Struts(JSP, Actions) 2. Simple class(Managers) to keep all our business logic code 3. IBATIS for database abstraction. Actions can call Managers to get the job done and Manager can use iBATIS to access DB. Is this a good approach or is there a better approach than this? Looking forward for your response. Have a great day. Karthikeyan B - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Business Logic :: Best Practices
> :) Basically, the same reason web applications and struts applications
> need a container. :)
hmm... disagreed. Web applications need a container so they don't need
to handle the http protocol theirself, handle jsps, taglibs and all the
other stuff.
struts itself is a framework, not a container.
> Being able to instantiate objects using a XML driven factory is very,
> very convenient, and make programing strategies possible that would be
> otherwise impractical.
You are describing an abstract factory, which is a well known pattern
and can be implemented with 3 classes.
>
> Consider how difficult a Struts application would be to code if you
> had to create all the objects in the struts-config through calls to
> new. Possible, but, very messy and very verbose.
See above. Actually I had my own 'struts' for year ago, and moved to
struts because of the taglibs.
>
> Also, in practice, you often end up making some (or all) of your
> business objects singletons. Containers like Spring give you a quick
> and consistent way to create singletons, when you need them, and
> instant classes when you don't.
I have an eclipse template for that :-)
private static ${enclosing_type} instance;
private ${enclosing_type}(){
}
public static synchronized ${enclosing_type} getInstance(){
if (instance==null){
instance = new ${enclosing_type}();
}
return instance;
}
I'm using a web container because:
I don't want to handle http.
I don't want to compile jsps.
I don't want to provide taglib handling.
The lifecycle of my code is defined by the web-page and very well
implemented in the web container.
I do not use an application container because:
I have none of the above problems there.
I don't want anything to eat away resources.
The lifecycle of the component is defined by application design.
In other words:
Why should I use a container instead of a framework.
The difference between container and framework as I see it is the flow
of control:
Container defines the lifecycle of a component and the communication
between components.
Framework provides tools to define the lifecycle of a component and
abstraction layers for the communication.
In other words: A container defines how you have to write your code
(e.g. ejb), a framework gives you possibilities to use already written
code.
Am I missing something?
Leon
>
> -Ted.
>
> On Fri, 11 Mar 2005 15:38:01 +0100, Leon Rosenberg
> <[EMAIL PROTECTED]> wrote:
> >
> > Why do you need a container? Or why do I need a container?
> >
> > Leon
> >
> > On Fri, 2005-03-11 at 07:27 -0600, NetSQL wrote:
> > > I used Hivemind and switch to CoR, which I consider a light weight
> > > container.
> > > Good article on CoR at onJava.com.
> > >
> > > .V
> > >
> > > Manfred Wolff wrote:
> > > >
> > > > Ted.
> > > >
> > > > +1 to this approach. I prefer leightweight container such as hivemind to
> > > > manage the entrypoints to the business logic. Hivemind is easy to learn
> > > > and you have the benefit, that the lifecycle of the business components
> > > > may be steered too (such as pooled components, singletons etc.). Other
> > > > containers like spring or picocontainer are also well.
> > > >
> > > > -Manfred
> > > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Business Logic :: Best Practices
:) Basically, the same reason web applications and struts applications need a container. :) Being able to instantiate objects using a XML driven factory is very, very convenient, and make programing strategies possible that would be otherwise impractical. Consider how difficult a Struts application would be to code if you had to create all the objects in the struts-config through calls to new. Possible, but, very messy and very verbose. Also, in practice, you often end up making some (or all) of your business objects singletons. Containers like Spring give you a quick and consistent way to create singletons, when you need them, and instant classes when you don't. -Ted. On Fri, 11 Mar 2005 15:38:01 +0100, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > > Why do you need a container? Or why do I need a container? > > Leon > > On Fri, 2005-03-11 at 07:27 -0600, NetSQL wrote: > > I used Hivemind and switch to CoR, which I consider a light weight > > container. > > Good article on CoR at onJava.com. > > > > .V > > > > Manfred Wolff wrote: > > > > > > Ted. > > > > > > +1 to this approach. I prefer leightweight container such as hivemind to > > > manage the entrypoints to the business logic. Hivemind is easy to learn > > > and you have the benefit, that the lifecycle of the business components > > > may be steered too (such as pooled components, singletons etc.). Other > > > containers like spring or picocontainer are also well. > > > > > > -Manfred > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- HTH, Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Business Logic :: Best Practices
Yep. Lately, I've started writing inner classes to access the business logic for a particular transaction script. The inner classes take input in a way conventient to the client, (say, by passing in an ActionForm,) use that input to interact with the business classes, and return the output in a way convenient to the client. I make these helpers throw-away inner classes so that they can stay very focused on a particular transaction script. Making them inner classes eliminates the temptation to try and share them, creating yet-another-layer. Inner clases also help reduce file-management bloat. It boils down to [Commands -- Business Rules and Persistence Logic] | [Business-Controller (CoR Catalog)] | [Helper (inner class)] | [Action/Code-Behind/Backing-Bean] The Helpers know which Transaction Scripts to call (IDs in the Catalog), but all the event handlers (Actions, Code-Behind, Backing Bean) know to do is call the Helpers. The Command is where the rubber meets the road. Here I make direct calls to iBATIS or JDBC or ADO or LDAP or Hibernate, or whatever. Since I can always replace a Command implementation if any of these details change, I don't worry about having another layer of abstraction. At first, I had the Commands calling gizmos like the iBATIS DAO, but there didn't seem to be any point. The Catalog is already a logical abstraction, so I cut to the chase, and now let the Commands call iBATIS and such directly. Of course, the Helpers are an example of the Facade pattern. -Ted. On Fri, 11 Mar 2005 05:58:40 -0700, Larry Meadors <[EMAIL PROTECTED]> wrote: > Yes. > > You are describing almost exactly how I write my struts code. > > Here are the components I would use to maintain a Customer table: > - com.myorg.domain.bean.Customer.java > - com.myorg.domain.dao.CustomerDao.java (interface) > - com.myorg.domain.service.CustomerService.java (interface) > - com.myorg.domain.dao.ibatis.mapping.Customer.xml (sql map) > - com.myorg.domain.dao.ibatis.CustomerDaoImpl.java (DAO implementation) > - com.myorg.domain.service.impl.CustomerServiceImpl.java (service > implementation) > - com.myorg.domain.web.customer.CustomerAction.java (DispatchAction) > - com.myorg.domain.web.customer.CustomerForm.java (includes nested bean) > > I would then have 2 jsps (list.jsp and edit.jsp) that are in the > WEB-INF/jsp/customer/ directory. > > I make the interfaces between the service and dao layer to simplify > testing. It is super easy to write a faux dao impl for testing your > service class, and equally easy to write one for the service interface > when testing the action. > > Larry > > On Fri, 11 Mar 2005 14:57:51 +0530, karthikeyan balasubramanian > <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > Struts DB Access Best Practices thread gave me great insight on how > > I should proceed with db operations. > > > > I have one more question. Where do you keep your business logic > > code. Right now I am thinking to use > > > > 1. Struts(JSP, Actions) > > 2. Simple class(Managers) to keep all our business logic code > > 3. IBATIS for database abstraction. > > > > Actions can call Managers to get the job done and Manager can use > > iBATIS to access DB. > > > > Is this a good approach or is there a better approach than this? > > > > Looking forward for your response. > > > > Have a great day. > > > > Karthikeyan B > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- HTH, Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Business Logic :: Best Practices
Why do you need a container? Or why do I need a container? Leon On Fri, 2005-03-11 at 07:27 -0600, NetSQL wrote: > I used Hivemind and switch to CoR, which I consider a light weight > container. > Good article on CoR at onJava.com. > > .V > > Manfred Wolff wrote: > > > > Ted. > > > > +1 to this approach. I prefer leightweight container such as hivemind to > > manage the entrypoints to the business logic. Hivemind is easy to learn > > and you have the benefit, that the lifecycle of the business components > > may be steered too (such as pooled components, singletons etc.). Other > > containers like spring or picocontainer are also well. > > > > -Manfred > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Business Logic :: Best Practices
I used Hivemind and switch to CoR, which I consider a light weight container. Good article on CoR at onJava.com. .V Manfred Wolff wrote: Ted. +1 to this approach. I prefer leightweight container such as hivemind to manage the entrypoints to the business logic. Hivemind is easy to learn and you have the benefit, that the lifecycle of the business components may be steered too (such as pooled components, singletons etc.). Other containers like spring or picocontainer are also well. -Manfred - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Business Logic :: Best Practices
Yes. You are describing almost exactly how I write my struts code. Here are the components I would use to maintain a Customer table: - com.myorg.domain.bean.Customer.java - com.myorg.domain.dao.CustomerDao.java (interface) - com.myorg.domain.service.CustomerService.java (interface) - com.myorg.domain.dao.ibatis.mapping.Customer.xml (sql map) - com.myorg.domain.dao.ibatis.CustomerDaoImpl.java (DAO implementation) - com.myorg.domain.service.impl.CustomerServiceImpl.java (service implementation) - com.myorg.domain.web.customer.CustomerAction.java (DispatchAction) - com.myorg.domain.web.customer.CustomerForm.java (includes nested bean) I would then have 2 jsps (list.jsp and edit.jsp) that are in the WEB-INF/jsp/customer/ directory. I make the interfaces between the service and dao layer to simplify testing. It is super easy to write a faux dao impl for testing your service class, and equally easy to write one for the service interface when testing the action. Larry On Fri, 11 Mar 2005 14:57:51 +0530, karthikeyan balasubramanian <[EMAIL PROTECTED]> wrote: > Hi all, > > Struts DB Access Best Practices thread gave me great insight on how > I should proceed with db operations. > > I have one more question. Where do you keep your business logic > code. Right now I am thinking to use > > 1. Struts(JSP, Actions) > 2. Simple class(Managers) to keep all our business logic code > 3. IBATIS for database abstraction. > > Actions can call Managers to get the job done and Manager can use > iBATIS to access DB. > > Is this a good approach or is there a better approach than this? > > Looking forward for your response. > > Have a great day. > > Karthikeyan B > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Business Logic :: Best Practices
Ted. +1 to this approach. I prefer leightweight container such as hivemind to manage the entrypoints to the business logic. Hivemind is easy to learn and you have the benefit, that the lifecycle of the business components may be steered too (such as pooled components, singletons etc.). Other containers like spring or picocontainer are also well. -Manfred Ted Husted wrote: As to business objects, the usual advice is to use Plain Old Java Objects (POJOs). The current MailReader example application is an excellent example of creating a set of interfaces to represent business logic, then instantiating a set of classes to implement the business logic. The MailReader uses a Struts PlugIn to create the business logic beans in application scope. Another good approach is to use Spring to create your business objects. Here, you might use a PlugIn to create the Spring instance in application scope, and then call the Spring instance to create everything else. Of course, my favorite way to manage business objects now is as a Chain of Responsbility. But, to get started, you probably want to use plain old business beans, as the MailReader does. All this is to say, option 2. The Actions call the business beans, and the beans do all the heavy lifiting. (Actions shouldn't know *how* to do things, just who to ask to get things done.) The iBATIS DAO layer is cool, but if you don't need a switchable DAO, you can do the same thing using your own interfaces. Of course, my favorite way to do business logic now is using the Chain of Responsiblity. But, that's a bit bleeding edge right now :) -Ted. On Fri, 11 Mar 2005 14:57:51 +0530, karthikeyan balasubramanian <[EMAIL PROTECTED]> wrote: Hi all, Struts DB Access Best Practices thread gave me great insight on how I should proceed with db operations. I have one more question. Where do you keep your business logic code. Right now I am thinking to use 1. Struts(JSP, Actions) 2. Simple class(Managers) to keep all our business logic code 3. IBATIS for database abstraction. Actions can call Managers to get the job done and Manager can use iBATIS to access DB. Is this a good approach or is there a better approach than this? Looking forward for your response. Have a great day. Karthikeyan B - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- === Dipl.-Inf. Manfred Wolff Software Engineer --- http://www.manfred-wolff.de http://www.struts-it.org --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts Business Logic :: Best Practices
Hello Ted, I am interested in knowing how will you tackle The businessLogic issue with CoR.. And how that approach differs from having an interface for your Business logic where the implementation is configured via Spring.. Could you clarify your approach with a short sample? Thanx in advance and regards Marco -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: 11 March 2005 11:03 To: Struts Users Mailing List; karthikeyan balasubramanian Subject: Re: Struts Business Logic :: Best Practices As to business objects, the usual advice is to use Plain Old Java Objects (POJOs). The current MailReader example application is an excellent example of creating a set of interfaces to represent business logic, then instantiating a set of classes to implement the business logic. The MailReader uses a Struts PlugIn to create the business logic beans in application scope. Another good approach is to use Spring to create your business objects. Here, you might use a PlugIn to create the Spring instance in application scope, and then call the Spring instance to create everything else. Of course, my favorite way to manage business objects now is as a Chain of Responsbility. But, to get started, you probably want to use plain old business beans, as the MailReader does. All this is to say, option 2. The Actions call the business beans, and the beans do all the heavy lifiting. (Actions shouldn't know *how* to do things, just who to ask to get things done.) The iBATIS DAO layer is cool, but if you don't need a switchable DAO, you can do the same thing using your own interfaces. Of course, my favorite way to do business logic now is using the Chain of Responsiblity. But, that's a bit bleeding edge right now :) -Ted. On Fri, 11 Mar 2005 14:57:51 +0530, karthikeyan balasubramanian <[EMAIL PROTECTED]> wrote: > Hi all, > > Struts DB Access Best Practices thread gave me great insight on how > I should proceed with db operations. > > I have one more question. Where do you keep your business logic > code. Right now I am thinking to use > > 1. Struts(JSP, Actions) > 2. Simple class(Managers) to keep all our business logic code > 3. IBATIS for database abstraction. > > Actions can call Managers to get the job done and Manager can use > iBATIS to access DB. > > Is this a good approach or is there a better approach than this? > > Looking forward for your response. > > Have a great day. > > Karthikeyan B > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- HTH, Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Business Logic :: Best Practices
As to business objects, the usual advice is to use Plain Old Java Objects (POJOs). The current MailReader example application is an excellent example of creating a set of interfaces to represent business logic, then instantiating a set of classes to implement the business logic. The MailReader uses a Struts PlugIn to create the business logic beans in application scope. Another good approach is to use Spring to create your business objects. Here, you might use a PlugIn to create the Spring instance in application scope, and then call the Spring instance to create everything else. Of course, my favorite way to manage business objects now is as a Chain of Responsbility. But, to get started, you probably want to use plain old business beans, as the MailReader does. All this is to say, option 2. The Actions call the business beans, and the beans do all the heavy lifiting. (Actions shouldn't know *how* to do things, just who to ask to get things done.) The iBATIS DAO layer is cool, but if you don't need a switchable DAO, you can do the same thing using your own interfaces. Of course, my favorite way to do business logic now is using the Chain of Responsiblity. But, that's a bit bleeding edge right now :) -Ted. On Fri, 11 Mar 2005 14:57:51 +0530, karthikeyan balasubramanian <[EMAIL PROTECTED]> wrote: > Hi all, > > Struts DB Access Best Practices thread gave me great insight on how > I should proceed with db operations. > > I have one more question. Where do you keep your business logic > code. Right now I am thinking to use > > 1. Struts(JSP, Actions) > 2. Simple class(Managers) to keep all our business logic code > 3. IBATIS for database abstraction. > > Actions can call Managers to get the job done and Manager can use > iBATIS to access DB. > > Is this a good approach or is there a better approach than this? > > Looking forward for your response. > > Have a great day. > > Karthikeyan B > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- HTH, Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts Business Logic :: Best Practices
Hi all, Struts DB Access Best Practices thread gave me great insight on how I should proceed with db operations. I have one more question. Where do you keep your business logic code. Right now I am thinking to use 1. Struts(JSP, Actions) 2. Simple class(Managers) to keep all our business logic code 3. IBATIS for database abstraction. Actions can call Managers to get the job done and Manager can use iBATIS to access DB. Is this a good approach or is there a better approach than this? Looking forward for your response. Have a great day. Karthikeyan B - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
