• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

how to decouple sql in servlet

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

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.


It's my understanding that the application that I'm assigned to will be being converted to Struts (I will be doing this: yes, I am generally aware of WHAT Struts is; no, I have never read anything instructional {i.e., a book or online tutorial} about how to use it).
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).
Anyway, this is my first post in any forum of JavaRanch so please:
  • If I've posted to the wrong forum, forgive me;
  • If I'm doomed to fail in my task, let me down gently;
  • If there's hope for me after all, BRING IT ON!


  • Eagerly awating your replies, I am,
    [ March 09, 2004: Message edited by: richard foreau ]
    [ March 09, 2004: Message edited by: richard foreau ]
     
    Sheriff
    Posts: 67746
    173
    Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi richard, welcome to the Ranch!


    # If I've posted to the wrong forum, forgive me;


    Thanks for the concern, but no. Since we don't have a forum dedicated to web apps or web app architecture, the Servlets and JSP forums seem to serve that function.


    # If I'm doomed to fail in my task, let me down gently;


    Not at all. In fact, you'll be doing a good thing.
    I am assuming that currently the DB access is done via SQL/JDBC directly in the servlet (controller) classes or (worse) directly in the JSPs. Factoring out such access will make your app better all around.
    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.
    Armed with these terms, you are set to start digging in. Search these forums and the net for these terms and you'll be well on your way.
     
    ranger
    Posts: 17347
    11
    Mac IntelliJ IDE Spring
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    And also keep in mind, just because this is a web application/J2EE, doesn't mean that you can't use regular Java classes that you make up.
    Mark
     
    richard foreau
    Greenhorn
    Posts: 5
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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!) :-)

     
    Ranch Hand
    Posts: 580
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    What I would recommend would be to try to abstract out a "data access layer" (much like you describe). 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. Take a look at the Data Access Object pattern (Sun J2EE Patterns Catalog). 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! :-)
     
    Ranch Hand
    Posts: 5093
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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.


    Nice first job, smart company.
    Will have you see almost all the codebase, thus getting you up to speed the more quickly, while at the same time providing them value.


    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).


    Not knowing the application I can't tell if EJB is the best choice in your case, but it doesn't have to be.


    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?


    That would be a good way to start.
    On top of that you would build a layer of business logic objects representing concepts in your application rather than directly mapping the database tables (what most EJB solutions advocate, see the snag already?).
    These objects would basically know how to store and load themselves and what other objects they need to load and store (they can make use of each other).
     
    richard foreau
    Greenhorn
    Posts: 5
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi, James.

    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).


    Agreed, and I will give the pattern you mentioned a good going-through. Hopefully it will clear a few things up for me (I guess I've been a bit spoiled by the ease-of-use factor that I've experienced in the Visual Foxpro development environmnet; time to roll up my sleeves and get down into the nuts-n-bolts, no? )

    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.


    Again, I agree. I'm a little confused, though: if the servlets themselves ought not to contain the business logic/objects, what would you call the servlet "layer" of this application? Are servlets merely a bridge between the ui and the business tier?

    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! :-)


    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 ]
     
    Ranch Hand
    Posts: 342
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    These are questions that I am also facing at the moment. A current web-app that mostly uses <shudder>ColdFusion</shudder> is to be refactored completely using Java so that it actually works and doesn't bring the server down twice a day :roll: We want to do this using MVC so that it is more easily maintained in the future and so we can lift bits out to reuse in other applications.
    We may or may not be using J2EE, probably more likely just JSP's and servlets. This was our interpretation...
    MODEL
    The way we will approach this is to build up a library of classes that cope with specific tasks we want our application to perform and to represent the various data structures we handle (capabilities like retrieve this data, generate that file etc). These are the UTILS and may be applicable to other similar applications in the future which is good.
    CONTROLLER
    We will use servlets here to talk to the library of utilities in the MODEL
    VIEW
    In turn, a series of JSP pages will arrange the interface, report messages to the user and get user input by passing information to the servlets in the CONTROLLER
    I too would be interested in knowing if this is a reasonable interpretation of the MVC for a web app
     
    Jeroen Wenting
    Ranch Hand
    Posts: 5093
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Again, I agree. I'm a little confused, though: if the servlets themselves ought not to contain the business logic/objects, what would you call the servlet "layer" of this application? Are servlets 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.
    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
    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.
    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).
     
    James Carman
    Ranch Hand
    Posts: 580
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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!

    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 ]

     
    richard foreau
    Greenhorn
    Posts: 5
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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.


    This makes sense to me although, from a physical architecture standpoint, it "feels" counter-intuitive to categorize something that's physically located on the server (the servlets) as part of the client app (not arguing the point here, just thinking aloud ).

    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


    2 questions about the 5-tier model you describe, above:
  • instead of browser (1), servlet/jsp (2), wouldn't it be more accurate to describe the tiers as browser/jsp (1), servlet (2) ?
  • i'm intrigued by the persistence layer; what, specifically, would be its function (in addition to decoupling business logic from 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.


    My personal style is to read/research best-practices first (whenever possible, that is) and then to embark upon a journey with those ideals firmly in mind. As you point out, the archetype isn't always the most practically implementable approach but, for me, keeping it in mind tends to result in a cleaner implementation overall than if I hadn't had that ideal in mind (heh, dare I suggest here that "great minds think alike"? )

    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).


    Not being familiar (yet!) with the inner structure/workings of Struts, I'm not clear on how I'd have to approach my own coding style in order to accomodate an easy-in, easy-out mechanism for in-/ex-cluding Struts (or any other framework for that matter).
    Do you think it would be beneficial to familiarize myself with Struts *before* beginning these decoupling efforts (moving the sql and business logic out of the servlets and into their own classes/tiers) that we've been discussing in this thread?
    Thanks for your feedback so far; looking forward to more (from you and others!)
    richard
    [ March 11, 2004: Message edited by: richard foreau ]
     
    richard foreau
    Greenhorn
    Posts: 5
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by James Carman:
    Well, Servlets are not, themselves, part of the "presentation layer" (IMHO). I consider them "presentation support."


    It seems to me that this notion of "presentation support" is less a matter of architectural necessity, more a matter of stateless-/web-related necessity.
    Though admittedly not a software architectural guru by any measure, I don't recall ever being exposed to a "presentation support" layer on the desktop, or in a state-friendly networking environment. In my limited experience, the UI (usually?) talks directly to the business objects.
    Am I discerning this dynamic accurately or am I still missing something?

    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.


    When I'm canvassing unfamiliar territory (as I am doing here), my rule of thumb is to simplify as much as possible in order to identify & understand the core idea. If by simplifying I've eliminated something significant, by all means please do inform my ignorance/naivete!
    Let's take a simple login: name and password. UI passes the form data to a servlet. Servlet passes the name/password on to a business object, which then verifies the login info.
    In the direction FROM the ui TO the business layer, the servlet appears (to me) to act like a "presentation support" element (since the ui itself cannot invoke a business object unless that business object is contained within the invoked servlet?).
    If the login succeeds, the business object returns to the servlet a TRUE value, else FALSE. Now the servlet decides, on the basis of this return value, which page to display next.
    In the director TO the ui FROM the business layer, the servlet appears (again, to me) to act more like another component of the business layer (doing more? than mere presentation support) in that in that it contains (business?) logic that decides which page to display next?
    Somebody please... school me!

    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.


    If I understand what you've suggested, above, it seems to imply that a servlet -- by virtue of the fact that it would (usually?) contain references to the Servlet/JSP API -- should not be the place for business logic... is that what you meant to convey?

    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!


    I haven't any experience with any commercial IDE's so I don't know what to do with the IDE-info. you've shared, above (i.e., I don't have a concrete referent for what your webapp module contains).
    As for the dependency comment, that makes sense to me. I seem to remember a concept from Riel's (sp?) "Object Oriented Design Heuristics" book that, similar to what you said, a container must know about it's contents, but the contents need not know anything about their container.
    Might be stretching things a bit by this analogy, but I guess I'm mapping the presentation layer (web module?) into the role of "container", and the business logic/layer into the role of "contents". This makes a nice analogue for me to understand and remember your idea that "The web module depends on the business logic module, but not vice-versa".
    Whew! So much for me to synthesize and so little time!
    As always, much obliged for your time and thoughtful replies!
    [ March 11, 2004: Message edited by: richard foreau ]
     
    James Carman
    Ranch Hand
    Posts: 580
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Your right, the UI DOES talk to the business layer (either directly or indirectly through some proxy). It has to! I didn't say that servlets weren't a part of the UI. To me, servlets (or action beans) act as the "controller" in an MVC UI architecture. The JSPs act as the "view." The view is responsible for presenting data (the model) to the user and providing a way for the user to communicate/interact with the system (links/forms in a webapp). The controller reacts to the user's input by invoking some business logic and deciding which "view" to show next. This is just the way I think of things when architecting a web application and the way I like to separate the concerns.
    As far as the "business logic doesn't reference Servlet API" comment, I mean that your business logic should be "UI framework and data source agnostic." Meaning, that the same business logic used in your webapp can be used in a Swing API, an Applet, etc. Also, if you design it right, the DAO layer sits between your business logic and the data storage mechanism (RDBMS, LDAP, file system, OODBMS, mock objects). If you architect your business logic this way, it is very EASY to unit test it (I try to use Test-Driven Design). All you have to do is substitute in a mock implementation (which returns known values) for your DAO layer. That being said, my business logic service implementations look similar to the following...

    Now, that's a crude example, but I hope you get the idea. I try to use interfaces (AccountDao and AccountServices in this example) wherever possible and I use a container like HiveMind (Jakarta Commons Sandbox) to "weave" all of the actual implementations (calling setAccountDao, for example) together.
     
    Consider Paul's rocket mass heater.
    reply
      Bookmark Topic Watch Topic
    • New Topic