quick context: i've been working as a software developer since 1988; although i've done some self-learning in java via "thinking in java, 1st edition" (eckel) and "learning java, 2nd edition" (aka "o'reilly's tiger book" by niemeyer & knudsen), i've never actually worked in it before.
<blockquote><font size="1" face="Verdana, Arial">code:</font><hr><pre><font size="2"><br />,-. richard foreau<br /> ( ..) <br /> .--oo0--(_)--0oo--------------------------------------.<br /> |<br /> | 1. ask questions; carefully listen to the answers.<br /> | 2. document your perceptions using words, diagrams,<br /> | images, prototypes, whatever.<br /> | 3. solicit feedback about your documentation and<br /> | refine appropriately.<br /> | 4. code unit tests before coding solutions; testing<br /> | is a mandatory element in software development!<br /> | 5. application stability, fitness, ease of use, and<br /> | performance (along with user satisfaction) are<br /> | your best references.<br /> `-----------------------------------------------------'<br /></font></pre><hr></blockquote>
# If I've posted to the wrong forum, forgive me;
# If I'm doomed to fail in my task, let me down gently;
Originally posted by Bear Bibeault:
[QB]Hi richard, welcome to the Ranch!
Thanks, Bear!
I am assuming that currently the DB access is done via SQL/JDBC directly in the servlet (controller) classes.... Factoring out such access will make your app better all around.
Architecturally, I completely agree. Where I feel a sense of confusion is WHERE to factor out such access. If I'm not using EJB's, should I just create something like an SQL class in the "utils" package? Why or why not?
Your DB is probably storing data that needs to be brought into the app to represents data object which I will call the Model, the servlets then interface to this abstracted model rather than deal with the DB directly. The servlets merely control the flow of the app and I'll term them the Control. The UI of your app, termed the View is composed of the JSP pages.
Hence your app becomes layered as Model/View/Control. This is known as the MVC pattern. And even though it is not really possible to create a "true" MVC pattern in a wep app (due to restructions of the HTTP request/response protocol) a good approximation can be made and this is generally known as the Model 2 patterm.
Am distantly familiar with MVC... what, precisely, about this architecture should I be looking for? (sorry if this is an overly-generic question but I AM a newbie!) :-)
James Carman, President<br />Carman Consulting, Inc.
Originally posted by richard foreau:
Hello to Everyone!
I just landed a job maintaining a jsp/servlet/oracle application and among my first tasks is to decouple all the sql that's currently embedded in the servlets.
I've been told by the person who is my mentor (guess that makes me -- positionally speaking -- an apprentice, eh? ) that although ejb's are probably the best way to decouple the code, we're not going to be using that approach in this application because (insert some not-quite-intelligible explanation here).
Architecturally, I completely agree. Where I feel a sense of confusion is WHERE to factor out such access. If I'm not using EJB's, should I just create something like an SQL class in the "utils" package? Why or why not?
42
Originally posted by James Carman:
What I would recommend would be to try to abstract out a "data access layer" (much like you describe). Take a look at the Data Access Object pattern (Sun J2EE Patterns Catalog).
Originally posted by James Carman:
You should also try to tear out the business logic, which I'm sure is also in the servlets, since the data access code is in there. The business logic layer should use the data access layer to query/modify the database.
Originally posted by James Carman:
In Struts, a lot of folks make the mistake of putting the business logic inside the Action classes. The Action classes should talk to some sort of business logic object (you can use the business delegate pattern if you wish, also). To test your business logic, you can provide the business logic classes with "mock" implementations of your data access objects. Just a few pointers! :-)
<blockquote><font size="1" face="Verdana, Arial">code:</font><hr><pre><font size="2"><br />,-. richard foreau<br /> ( ..) <br /> .--oo0--(_)--0oo--------------------------------------.<br /> |<br /> | 1. ask questions; carefully listen to the answers.<br /> | 2. document your perceptions using words, diagrams,<br /> | images, prototypes, whatever.<br /> | 3. solicit feedback about your documentation and<br /> | refine appropriately.<br /> | 4. code unit tests before coding solutions; testing<br /> | is a mandatory element in software development!<br /> | 5. application stability, fitness, ease of use, and<br /> | performance (along with user satisfaction) are<br /> | your best references.<br /> `-----------------------------------------------------'<br /></font></pre><hr></blockquote>
SCJP 1.4, www.gsi3d.org.uk
42
Originally posted by richard foreau:
Hi, James.
Pointers much appreciated, believe me! I haven't begun to scratch the surface of Struts but I am struck, as in the previous paragraph, with wondering whether the servlets (or in the case of Struts, the Action classes) ought to be thought of as anything more than a bridge between the ui and the business layer?
Looking forward to elaboration!
richard
[ March 10, 2004: Message edited by: richard foreau ]
James Carman, President<br />Carman Consulting, Inc.
Originally posted by Jeroen Wenting:
[i](responding to richard's question of whether "servlets are merely a bridge between the ui and the business tier?"...)
More or less.
In a client/server environment the servlets and JSPs together would form the client application, the business objects and everything behind them the serverside application.
Originally posted by Jeroen Wenting:
In a web application there are several more tiers added of course.
The servlet forms a gateway between the presentation/input capture tier and the business tier.
You can add (and many do) yet another tier between the business logic and the datastore (or backend process) to decouple those as well, leading to what's effectively a 5 tier model: browser-servlet/JSP-business logic-persistence layer-datastore
Originally posted by Jeroen Wenting:
If carefully designed each layer could in theory be swapped out for something else without touching the rest of the application.
In practice that's often too much of a good thing for performance and speed of development and some coupling occurs but it's good to keep the ideal in mind and try to work towards it especially in a refactoring project like you're involved in.
Originally posted by Jeroen Wenting:
Struts provides hooks for most of these tiers, but try to code your stuff so that another framework can easily be plugged in (this means that you may end up with an interface layer between your code and Struts).
<blockquote><font size="1" face="Verdana, Arial">code:</font><hr><pre><font size="2"><br />,-. richard foreau<br /> ( ..) <br /> .--oo0--(_)--0oo--------------------------------------.<br /> |<br /> | 1. ask questions; carefully listen to the answers.<br /> | 2. document your perceptions using words, diagrams,<br /> | images, prototypes, whatever.<br /> | 3. solicit feedback about your documentation and<br /> | refine appropriately.<br /> | 4. code unit tests before coding solutions; testing<br /> | is a mandatory element in software development!<br /> | 5. application stability, fitness, ease of use, and<br /> | performance (along with user satisfaction) are<br /> | your best references.<br /> `-----------------------------------------------------'<br /></font></pre><hr></blockquote>
Originally posted by James Carman:
Well, Servlets are not, themselves, part of the "presentation layer" (IMHO). I consider them "presentation support."
Your JSPs (or Velocity templates or whatever) are your "presentation layer." The "presentation support" layer is responsible for connecting to (and invoking) your business logic and webapp flow of control logic (which screen to show next, etc.). The "presentation support" transforms web forms/requests into data that can be used to invoke business logic methods/services.
One good rule of thumb: your business logic layer should not contain any references to the Servlet/JSP API at all. That way, it is completely decoupled from the presentation layer.
In IntelliJ IDEA (my IDE of choice, and I'm not trying to start a "my favorite IDE war" here) :-), I set up different modules for the webapp and the business logic in my project. I only expose the Servlet API to my web module. This helps me enforce my "best practice." The web module depends on the business logic module, but not vice-versa. Ok, done with my rant. Hope that helps! Have fun!
<blockquote><font size="1" face="Verdana, Arial">code:</font><hr><pre><font size="2"><br />,-. richard foreau<br /> ( ..) <br /> .--oo0--(_)--0oo--------------------------------------.<br /> |<br /> | 1. ask questions; carefully listen to the answers.<br /> | 2. document your perceptions using words, diagrams,<br /> | images, prototypes, whatever.<br /> | 3. solicit feedback about your documentation and<br /> | refine appropriately.<br /> | 4. code unit tests before coding solutions; testing<br /> | is a mandatory element in software development!<br /> | 5. application stability, fitness, ease of use, and<br /> | performance (along with user satisfaction) are<br /> | your best references.<br /> `-----------------------------------------------------'<br /></font></pre><hr></blockquote>
James Carman, President<br />Carman Consulting, Inc.
Consider Paul's rocket mass heater. |