Hi...
Why one should use a Collection object which contains javabean objects (one for each for each database row) over ResultSet object in MVC? What are the advantage on not using ResultSet in MVC at presentation layer?
I hope my question is clear enough.
Cheers.
In a function that gets data from a database, you open a connection, get a resultSet and close the connection. Then return data from the function.
Once the connection is closed, the resultSet is invalid. Therefore you need to copy its contents into some type of collection and return that from the function. You HAVE to close the connection before you leave the function (try/catch/finally). The connection is a valuable resource and must be opened and closed as quickly as possible.
Secondly, In MVC, there is a separation of concerns roughtly as follows:
Persistent layer:
Uses JSP to display data. Passed simple data structures from the business logic layer for display and instructions on what sections to display. Does not contain ANY logic from the other layers.
Example: dont put this on the page:
if ( data.length()==0) display this section.
The above is business logic.
Use this:
if ( dataModel.isDisplaySection1()==true) , therfore display the section.
The above shows the business logic decided to display or not display the section by setting isDisplaySection1 to true or false. Determining to make it true or false may involve some complex business logic than data.length()==0.
Control layer - navigation. Either a Struts Framework or simple central url routing servlet. Doesnt generate JSP, doesnt call sql. it passes the url request to the business logic layer which processes it, then passes the data the business logic which returns to whatever jsp page the business logic says to display.
Business logic layer
doesnt contain sql, doesnt contain control logic. It takes in the url request to determine what it wants (update button clicked), asks the persistent layer for data, and returns the data to the control layer.
Persistent layer
Takes in a request for data from the busines logic ( ie: getCustomers() ), queries the database ('select * from customers"), and returns the data as a collection to the business logic ( String[] customers).
I suggest you create a simple web site with one or two JSP pages and try out the above seperation of concerns. When a web site becomes hundreds of JSP pages and thousands of business logic functions, the above makes adding onto the web site possible. Without it, you get lost inall the logic trying to add just one JSP page.
Hi George,
Well this information is really useful. I appreciate that.
I have already implemented the Struts MVC with couple of approaches.
The situation is...i have many database search applications...for them i have implemented MVC with struts. I have tried three alternatives strategies..
JSP page fires url, the controller invokes an action (model/business logic). The model then fires a database query and gets ResultsSet... Now, the alternatives are...
1. The model processes the ResultSet objects and put them into ArrayList of arrays for View page...this is column wise distribution of a table... (weired..i know)
2. The model processes the ResultSet with beans. These bean objects are available through ArrayList object on View page.
3. The model obtains the ResultSet object and send to View page through servlet controller.
I know the second one is standard practice.. but my compeers think than it involves extra processing and give same fuctionality as the third one...
What do you think on it?
The other question is, is it a good approach to handle lot of small application applications like these through utilizing common classes and configuration file and to make it one big application?
> JSP page fires url, the controller invokes an action
> (model/business logic). The model then fires a
> database query and gets ResultsSet... Now, the
> alternatives are...
>
> 1. The model processes the ResultSet objects and put
> them into ArrayList of arrays for View page...this is
> column wise distribution of a table... (weired..i
> know)
>
> 2. The model processes the ResultSet with beans.
> These bean objects are available through ArrayList
> object on View page.
>
> 3. The model obtains the ResultSet object and send to
> View page through servlet controller.
>
> I know the second one is standard practice.. but my
> compeers think than it involves extra processing and
> give same fuctionality as the third one...
But as George said, 2 and 3 don't provide the same functionality. In order to use the ResultSet, the Connection to the Database must be kept open. The connection to the db is a precious resource, the longer it stays open, the longer someone else has to wait to get their results. So you want to read from the ResultSet and close the connection as soon as you can.
If you wait to read the ResultSet until you get to the JSP, then not only are you waiting longer to start reading from the connection, but you have to wait for buffers being filled and flushed, html to be generated, and any number of other unpredictable events that can occur. The connection will be open and unavailable for longer, and may be left hanging if something goes wrong.
Not only that, but the use of the ResultSet in the JSP makes for tough, hard to manage code. You can't just display what is given to you in a List (from the JSP's perspective), you have to walk through a ResultSet, futz with error handling, and get all around ugly code. Now what if your db schema changes? You have to re-do your JSP pages as well. Finally, if you keep the DB layer completely out of the JSP, you can test, manage, and modify your code in a command line/local java app environment. You don't need the JSP engine/server (and all the complexities that come with it) to test your code, just to display the results.
>
> What do you think on it?
>
> The other question is, is it a good approach to
> handle lot of small application applications like
> these through utilizing common classes and
> configuration file and to make it one big application?
I think many teams don't apprchiate the advantages in separation of concerns between the business logic layer and the database logic layer. I have worked with other people's code where the sql statements and its supporting code is embedded in the business logic. This makes JUNIT testing the sql code and JUNIT testing the business logic layer impossible to do separately. Also, if you are studying someone else's business logic to determine how it works, you cant see the forest through the trees due to all the database code embedded in it. One project I support written by another group has 14000 functions in it, business logic and database logic mixed together throughout.
*********
In answer to programmers wanting to avoid an additional processing step to optimize performance:
I ran into this resistance many times over the years and I still run into it today.
The biggest challenge today I believe in creating a web site or other type of large project is not tweaking every bit of performance out of every line of code
(a lot of programmers are preoccupied with this).
Instead, the single biggest problem is structuring a project in a modularized way that can be maintain and enhanced.
80% (literally) of all coding man hours goes into trying to add onto an existing large project that was so poorly structured that
it's nearly impossible to add to. Similarly, 90% (literally) of all large projects fail in part because the project grows so large that it
collapses on itself due to poor framework implementation and modularization.
Unfortunately most programmers must work on many failed projects before they begin to understand the failure is caused by these scalability issues.
Unfortunately, most programmers will never learn this because they go off to their next job without seeing the mess they left behind for someone else to deal with. They think since they completed the project, its a success, not realizing that the project will be added onto by other programmers over the following years (using many more man hours) and that they are cursing the original programmers for doing such a poor job. Also, management would praise the original programmers for being
such geniuses and wonder why the next programming team cant do the same with the existing code (debugging your own code is quick because how it works is still in your head, debugging someone else's code is a nightmare).
Example of scalability issues: I had a custom framework created by another team that left the company that took me 3 days to add one textfield to
a JSP page because the underlying framework couldn't handle it due to the fact that its functionality did something the underlying framework wasn't programmed to handle. I had to dive into the underlying undocumented framework to make the code changes to handle it.
As far as modularization goes, if anyone were to write a simple 'HelloWorld' web site, he would be amazed at all the layers of code it goes through to go from the server to the user to be displayed (server software package, browser software package, internet protocols, etc). Projects we create should be organized no differently.
Reading up on performance tuning java projects, it says to make the code as clear as possible over making it as fast as possible. At the end of the project, do performance tuning only where it provides significant performance enhancements. Why tune 200 functions and make them unreadable for a 0.04% increase in speed when removing the bottleneck in some other single function increases performance by 20%?
I'm not knocking writing code to perform well, but not at the expense of readability and modularization.
I learned modularization by creating a small project with two JSP pages and Struts, then refactoring it over and over again to get it modularization correct.
I didn't try to learn this on an actual project because there would be so many JSP pages, refactoring anything significant would take forever and I would also lose the focus of modularizing the code by being preoccupied with implementation issues.
null
Nice one...both of you. I appreciate your views.
I hope the team appreciate my efforts and your guidance.
By the way, anyone of you has any idea about benefits of implementing hibernate framework at persistence layer? Will it be beneficial to manage number of small projects within one singal framework (Struts and Hibernate) ?
Cheers.
> I think many teams don't apprchiate the advantages in
> separation of concerns between the business logic
> layer and the database logic layer. I have worked
> with other people's code where the sql statements and
> its supporting code is embedded in the business
> logic. This makes JUNIT testing the sql code and
> JUNIT testing the business logic layer impossible to
> do separately. Also, if you are studying someone
> else's business logic to determine how it works, you
> cant see the forest through the trees due to all the
> database code embedded in it. One project I support
> written by another group has 14000 functions in it,
> business logic and database logic mixed together
> throughout.
>
> *********
>
>
> In answer to programmers wanting to avoid an
> additional processing step to optimize performance:
>
> I ran into this resistance many times over the years
> and I still run into it today.
> The biggest challenge today I believe in creating a
> web site or other type of large project is not
> tweaking every bit of performance out of every line
> of code
> (a lot of programmers are preoccupied with this).
And wrongly so. You're right to say this is a preoccupation. The bestest most wonderfullest way to get performance out of your JVM is to write really straight-forward, solid OO code
Have a read of the following article
http://java.sun.com/developer/technicalArticles/Interviews/goetz_qa.html
