• Post Reply Bookmark Topic Watch Topic
  • New Topic

Beginner needing Java application restructuring advice

 
M Shiner
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Guys,

I'm probably just over concerning myself with the absolutely "best method" but I'm currently supporting a legacy application which is part of a big intranet portal for our company.

I'm getting pretty good at Java now but this is the first time with Java EE. So we're running a TomCat 7 server with this application on.

My concern is that many of the functions of this application have most/all of the Java logic within the JSP page. Some pages are just pure java in a JSPs which have parameters passed to it through other JSP. Seems like I need to start organising it a bit better.

I'm not very clued up on servlets nor any decent design patterns which would help me separate these into a front-end and back-end style (I heard MVC is something I should be looking at.. Unless anyone can recommend me a design pattern I can implement).

Before I restructure to that level (need to keep active development going), I thought about separating all the main functions into Java classes and just importing them in the JSP?

I know it gets included in the page so it's not much better than writing in out in the JSP. But I figured if I had small classes that carried out functions, they could be reused across many JSPs.

I'm asking if you think it's worth splitting the functions up into classes, just to visually take it out the JSPs? Or shall I wait and do a lot more readying before fully implementing a solid structure.

Thanks,

Mike J S
 
Madhav Turangi
Greenhorn
Posts: 16
1
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is a good intention to refactor the code. Identify the business logic within the JSPs from that deals with presentation. Start moving them out from JSPs into classes. Once the JSPs become light-weight, then re-consider the Java classes to further refactor them improving their quality. This is one approach that came into my mind, there could be some other approaches that might work better. Basically it has to start from somewhere. Refactoring the legacy application code takes more than one iteration.

 
M Shiner
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Madhav Turangi wrote:It is a good intention to refactor the code. Identify the business logic within the JSPs from that deals with presentation. Start moving them out from JSPs into classes. Once the JSPs become light-weight, then re-consider the Java classes to further refactor them improving their quality. This is one approach that came into my mind, there could be some other approaches that might work better. Basically it has to start from somewhere. Refactoring the legacy application code takes more than one iteration.


Okay thanks for your reply, it makes sense to do this step and eventually end up at proper structure in time. Never thought of it like that.

I wanted to add to my original question though, the application displays a large chunk of data which is fetched from a database. Taking the database logic out of the JSP, is there a good way I can create a reusable class giving I perhaps want to retrieve different fields from tables at different times?
I.e. One query retrieves all the applications users and displays them. But in another part, what if I want to display they're email address too? If that is not build into the original class there's no way to add this functionality afterwards. Unless I select everything and sieve through it in the JSP.

.. Rereading my question, I may be getting confused with business logic and presentation logic.

Thanks.
 
K. Tsang
Bartender
Posts: 3604
16
Firefox Browser Java Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Identifying the business logic is one thing. Identifying "common" utility-like functions is another.

For the database connection thing, you ought to look into connection pool and use JNDI to get such resource. The sql can be done using pure JDBC or JPA.

Talking about DB queries, you should consider data access object (DAO) pattern for all those DB select/update etc.

Your servlets can then use such DAO to fetch data accordingly.

I will suggest you start off with those JSPs that have the "least" java code in it. Such that, you can have a servlet/JSP mapping going/working.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65519
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
M Shiner wrote:I'm not very clued up on servlets nor any decent design patterns which would help me separate these into a front-end and back-end style (I heard MVC is something I should be looking at.. Unless anyone can recommend me a design pattern I can implement).


Please read this article carefully.
 
M Shiner
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:
M Shiner wrote:I'm not very clued up on servlets nor any decent design patterns which would help me separate these into a front-end and back-end style (I heard MVC is something I should be looking at.. Unless anyone can recommend me a design pattern I can implement).


Please read this article carefully.


Thank you for that article, it cleared a lot up for me. From this I have started moving some of the pure Java JSPs into servlets.

I'm using an HashMap objects to assign 'exception error's and other custom error messages. I then send them back to the JSP through getRequestDispatcher and display them using JSTL. i.e. ${callback.exception} - which will where I will write if an exception if thrown.

Is this a decent way of going about the JSP to servlet and back again communication?
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65519
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JSPs should only communicate back to servlets via form submissions or links. Because they are the view, they are the end of the road, so to speak, during request processing.
 
M Shiner
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes I see, sorry just to clarify;

A HTML form gets submitted and POSTed to the servlet, the servlet then processes the data. If there is an error, I send:

Where the JSP will catch the response which has 'callback' HashMap attached to it which has 'exception' key with my custom exception text.
It will display this using; JSTL
${callback.exception}
(Refreshing is a problem here because of the forwarder but since the form is incorrect it won't cause any problems other than more processing server-side).

In this case the user can adjust the form and resubmit which at this point it gets posted back to the servlet and processed again.

If no errors occur: I use
response.sendRedirect("NewPage.jsp?id=" + id);
where I can display the next step.

Hope this clears up the my method, so as far as I can see the JSP is only used for the view of servlet data and the page, and the servlet does all the processing.

I obviously take steps to ensure no database transactions or other commits happen unless the data is verified and error free.

This is just my way I have thought about doing it, if it's not quite on the money please shed some light on a better or more cleaner method.
After all you're the man to ask, Bear.

Thanks,

Mike
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65519
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It sounds close (I assume you have read the article I linked to earlier). I'm a little concerned about refreshes during an error, and that you are not using the error handling capabilities of the container.

What types of errors are you talking about?
 
M Shiner
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The errors that are stored in the HashMap are exceptions and custom errors.

For Example, at the end of the try/catch block I catch the exception and run:


So at the end of the program, I have:


Which allows me to determine if any error messages have been raised and I can then show the in JSP with

I also store custom messages so if a user needs a unique key to change a database record and I search for the key and it doesn't exist. I can put in the HashMap: ("nomatch", "Authentication string not found"); which I can display as well. The method works absolutely fine, and the only thing that's a tad worrying if there is an error, the forwarder will allow for a refresh which will post the same data again. It will only return the same error message again but it will be annoying for the user if it's done automatically. I want to make sure I'm getting good practices in early.

You mentioned error handling capabilities of the container? Can you explain a bit more detail please?

Thanks for your help,

Mike
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65519
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You should not be catching exceptions unless they are something you can recover from. For the other 99.9999999%, you should let them propagate out to the container. Then in the deployment descriptor (web.xml), you should declare a central servlet to perform error handling in a consistent and centralized manner.

See the error handling section of the Servlet Spec for details.
 
Dave Tolls
Ranch Hand
Posts: 2270
23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You shouldn't really be redirecting to that JSP.
It should either be a forward to the JSP, with all relevant data added to the request, or a redirect to another servlet to do whatever.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!