Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

RECENT ENTRIES


Tag Cloud


abbie appfuse birthday denver family grails gwt jack java javascript jhipster jsf linkedin maven roller skiing softwaresummit spring springmvc struts2 travel trish vacation webframeworks wicket
« Hibernate wins Jolt... | Main | The first day of... »
Thursday March 18, 2004

No more Struts in services layer

Yesterday, I did some more refactoring on AppFuse and got rid of Struts in AppFuse's services layer. Basically, I was using business delegates (a.k.a. Managers) to convert POJOs -> ActionForms and vise versa. So now the question is - why do I even need Managers and why don't I just talk directly to DAOs (as most sample webapps do)? I think the best justification is that Managers can be used by rich client apps and it abstracts the DAO implementation a bit more.

The question is - is there any point to using Managers in a webapps that will always be webapps (no rich client)? To be honest, probably not - but it does make for easy testing of the business logic. The main reason I did a Struts-purge is to get ready for adding other MVC options - most of which allow me to use POJOs in my view. I'm looking forward to adding Spring and WebWork support and I'm willing to bet these solutions will be a bit cleaner. Unfortunately, neither of these frameworks offer client-side validation support, but the good news is it's coming.

The best part about yesterday's refactoring? I ended up deleting more code than I added - which is always a good thing.

Posted in Java at Mar 18 2004, 06:58:16 PM MST 16 Comments
Comments:

Yea, I used to use them, about 5 years ago. Drop them like a wet dog!

Posted by Mike on March 19, 2004 at 02:14 AM MST #

I didn't write on single real life application where it was possible to invoke the DAO layer directly. The domain always is too complex and often the managers do a lot of things before invoking the DAO layer.

Posted by Unknown on March 19, 2004 at 02:15 AM MST #

I use Daos and Managers (but I call them Services) anyhow, in my Daos cant commit/ rollback any transactions, and they always participate in the current transaction, then the higher level Services come in, that way I can make many calls to different Daos inside one Service method that handles commit/rollbacks, just like the article for hibernate/spring integration at: http://hibernate.org/110.html I never use Daos in my Actions, I always use Services in the Actions and as far as JS client-side validation, it begun already with webwork2, yesterday actually!

Posted by Francisco Hernandez on March 19, 2004 at 02:40 AM MST #

All the web apps I write at work will always be webapps. However, DAOs don't meet all the requirements. Specifically, integration with previously existing web apps (EJBs and RMI) and mainframe integration (MQ).

So the services do serve a purpose, though perhaps some services will just be invoking the JDBC layer and could be inlined or built with code generation?

Posted by Koz on March 19, 2004 at 02:50 AM MST #

Absolutely the best reasons are listed above: 1) Transactions need to span DAOs 2) proper layering limits coupling and allows independent development on different layers, for instance adding different UI front ends ... and like Francisco said, Pat checked in the beginnings of client side validation yesterday in WebWork 2.0 CVS

Posted by Jason Carreira on March 19, 2004 at 05:05 AM MST #

I'm personally a proponent of the reduction of the number of layers given the current trend of mega layering everything. Koz, can you explain why DAOs don't meet the requirements for integration with EJB, RMI and mainframe since the requirement for DAOs is transparent access to a data source ? I'm with Matt concerning the myth of reusability. Jason evokes the case of adding different front ends. I'm sure this exists somewhere, but I've never professionally encountered the case where this was a requirement. Last but not least, Struts actions can be seen as realizing the Command pattern: they already are services.

Posted by Damien Bonvillain on March 19, 2004 at 01:07 PM MST #

Adding different front ends is a relatively rare case I used as an example based on what Matt was saying, but wanting to redesign the front end and possibly change page flows, etc is relatively common. Layering lets you evolve different layers somewhat independently. If your Actions are your services, this becomes a lot more work, especially if you're trying to do something like change the granularity of your pages.

Posted by Jason Carreira on March 19, 2004 at 02:12 PM MST #

Regarding using the same manager/services layer for web apps and rich clients: I worked on a Swing app that communicated with a services layer using DAOs. Later, another developer created a web app. He found that he couldn't use the existing services because they weren't at the right granularity for his needs. I designed the original services layer to minimize network hits (we have users coming over a WAN).

Posted by Neil Weber on March 19, 2004 at 05:16 PM MST #

Here is my vision. Managers are Business Delegates thus it implies for me that they are in charge of implementing business rules / services. DAOs are used inside Managers to perform CRUD operations. Struts Actions are used to manage the flow, deal with data back and forth with the UI, and access the business logic via the Managers.

Posted by Sébastien Pouillet on March 19, 2004 at 06:12 PM MST #

"The best part about yesterday's refactoring? I ended up deleting more code than I added - which is always a good thing."

So you removed code from AppFuse. Does that mean that users of AppFuse will have to write more code when they use Struts?

"The question is - is there any point to using Managers in a webapps that will always be webapps (no rich client)?"

Don't know enough about AppFuse or Struts, but have you tried to take a webapp and convert to rich client before? Are you *sure* that a webstart rich client could *never* take the place of a webapp? Plus, why does it have to take it's place, why not have both for some apps? Just a few curiosity questions...

Posted by gerryg on March 19, 2004 at 06:39 PM MST #

The DAO pattern, to me at least, is for interacting with data. A class that generates & saves your POJOs, handles CRUD operations etc.

However, the mainframes we interact with are typically performing services for us, with their own business rules. authorisePayment 2003548, send the customer a letter confirming modifications to their agreements. It just seems that cramming that behaviour into a getData/saveData style of interaction is wrong, but it certainly would be possible.

Posted by Koz on March 19, 2004 at 06:53 PM MST #

Jason - you make a good point about transactions across DAOs. I use Spring to declare transactions on my Managers - so I'm already doing this and it makes sense. I wanted to get confirmation that Managers are a Good Thing in a webapp, and it seems like the general consensus is that they are.

Gerry - I did remove code from AppFuse and No - users should end up writing less code than before. I used to have a "convert(Object)" method in my BaseManager class and that's now in BaseAction - so it's the same stuff in a different place. To see precisely what changed - here's the diff for UserManagerImpl.java and the diff for UserAction.java. UserManagerImpl became much simpler and UserAction refers to User (the POJO) in most cases, rather than UserForm (the ActionForm). IMO, it's much cleaner and simpler than before - and I wonder why I didn't do it this way a long time ago.

Thanks to all for the great feedback.

Posted by Matt Raible on March 19, 2004 at 06:55 PM MST #

I'd imagine that a lot of people will be adding web services to their webapps, which counts as a "different front end." I also think managers are handy to reduce code duplication in places you where you are populating select lists, etc in forms. (What Spring calls reference data)

Posted by James A. Hillyerd on March 19, 2004 at 10:08 PM MST #

Koz - I understand now your first comment, I thought you were dealing with persistance through RMI or MQSeries. Jason - Refactoring the original can really be a pain, but I'm not convinced that more layering is a good solution, modularization perhaps. There are two aspects with Struts Actions : (1)Command, nothing prevents you from chaining them if you want to keep some flexibility for the future, (2)screen oriented, usually implemented with DispatchAction and its siblings, in that case we are really stuck to the front end.

Posted by Damien Bonvillain on March 20, 2004 at 01:09 AM MST #

Lets define the word better as less code and simpler. For Struts in action I do a: formBean.populate(); which in turn does: void populate(x) { _dao.populate(x); } using DAO as a helper. This way I can re-use beans outside of Struts. I have been doing RIA development quite a bit, and I just moved the application layer to the browser. From the RIA I just get a handle on my DAO that returns an Arrraylist. So from Browser's RIA I do Array = RemoteObject.myDAO.populate(x); talking to the DAO. hth, .V

Posted by Vic on March 20, 2004 at 05:02 PM MST #

is it okey to expose domain objects directly to clients......?? service layer should never return domain objects directly.... remember what ejb spec. says... never expose your entities directly to clients... it should be hidden beneath a service layer... (session facade) services should never expose domain objects directly.. surely. services are must... 1) for transactions that spans over multiple dao. 2) access rights can be applied declaritevly over methods(like ejb method permissions) 3) no code duplication.. whenerver some specific task need to be done.. just use specific service Sudhir.

Posted by sudhir nimavat on January 10, 2007 at 09:52 AM MST #

Post a Comment:
  • HTML Syntax: Allowed