31 March 2004 - java_dev (original) (raw)

Just pasting what I wrote on a forum regarding multitier design. Not really sure if this is a good way of doing it or not though...

If you have access to use declarative security (which can be implmented in JAAS or realm for example) and know how to configure it for your app server, use it to perform your logins instead of Struts. Its one less thing to maintain. Thanks jaq for the clarification

Though EJBs are good, they make your architecture more complex, you have to balance the complexity of your architecture with the time you have to spend. Its usually better to get to market first and refactor things as you go along.

With the exception of using declarative security (which is more complicated than writing your own authentication system when you are starting) just create a simple web app with direct JDBC calls and no struts.

Once you have that working (its not going to be efficient and maintainable) you can try plugging in struts if you are going to expect a lot of changes going on in the user interface side, otherwise work on refactoring your data calls to EJBs.

When doing EJBs so SLSBs first to extract your data calls so you remove all JDBC calls from your web tier. Do the least painful things first which is to locate all your JDBC calls and push them down to the EJB tier. Note, put a lot more refactoring weight on the UI side because those get really tedious if you have to meddle with client requirements. Also when using EJBs use a cached home object (XDoclet will create this for you if you let it).

Once you have removed the JDBC calls from your web tier you now have another branch to deal with: convert direct JDBC class to Entity EJBs (or some other persistence framework) or move your business logic down to SLSB layer. To decide on this use the amount of data and users as your decision maker: if you have a lot of users and a lot of data or its getting to be that way, prioritize getting your Entity Beans created to take advantage of caching. If not move more of your existing "business" code down to the SLSB layer so you will reduce your web tier to just presentation stuff.

If you have to do the web tier refactoring you have two paths from here: extract common elements into tiles or use struts action mappings. If you have to do a lot of changes to the look and feel of your application, do the tiles conversion first, but before you do it just do simple jsp:includes then convert to tiles includes then convert to proper use of tiles.

Now if you have a client that changes their requirements for screen flow more often than styles, you should start moving to struts action mappings. Refactoring these would be easy if you are just dealing with presentation layer but if you are not so lucky, its just a bit more elbow grease. To get you started you have to map out the current site flow. You should end up with something like a state diagram. If you are just starting this refactoring I suggest you locate a simple flow (click data entry -> fill form -> submit -> go back to menu) and convert your pages to stuts pages. As you are doing this changes move your JSPs to the WEB-INF folder so you won't accidentally call these pages via JSP directly and make sure you have a 404 checker when you do these moves.

Just a caveat. These are more step by step suggestions, in real life you would probably skip a few steps just because you are more experienced and can quickly jump to the next refactoring.

To help you get started you may want to look at the maven:genapp there are a few generators to help you get started. I am not sure about the "complex" one though. But when I created the templates I was using most of the refactoring procedure I outlined above.