This week's book giveaway is in the Spring forum. We're giving away four copies of Pro Spring MVC with WebFlux: Web Development in Spring Framework 5 and Spring Boot 2 and have Marten Deinum & Iuliana Cosmina on-line! See this thread for details.
Hi, I'm trying to make a web app with form-based user authentication, with connection to a database. Very classical. All examples I've seen so far (2 or 3) establish the connection to the database directly on the page and hardcode the database user and password in it. Even if this is jsp code and isn't sent back to the client, I believe this is stupid from a security standpoint. So I thought it was better to establish the connection through a custom bean and call it in the JSP page. The bean must : 1. call the jdbc driver and make the connection to the database. 2. run a query against it with request-specific parameters. It seems obvious that the bean should have a session scope. However, the connection to the database need not be specific to each request. Only the query is specific. So what should i do ? create a "connection" bean with application scope and a query bean with session scope ? or use the same bean for both and a connection pooling ? Any remarks welcome. Thanks.
Well, since you put it that way, I'll pipe in my 2-cents in that I don't think you should do any of this from JSP pages at all. I'd recommend that you investigate the "Model 2" architecture pattern and perform all database activity in a servlet that then forwards off to a JSP page for display. If you reject such a pattern, then I'd say that abstracting your logic into beans (and off the pages) is the next best thing. In either pattern, I'd create a connection pool that 'lives' in application scope (no real need to make it per-session, is there?) to supply connections to the servlet or beans that need them for database operations. hth, bear P.S. Searching this and the Servlets forum for "Model 2" or "MVC" will yield lots of useful info. [ August 22, 2003: Message edited by: Bear Bibeault ]
Excellent ! Many thanks ! I actually saw this Model 2 / MVC talked about in several places and specifically related to jsp, on Sun's site. I know the Struts framework is a well-known implementation of it, but it's too complicated for me to digest now. I think I'm going to return to this site I saw the model 2 explained. I'm all for using patterns whenever possible. Thanks again.
As you rightly pointed out, Struts is merely an implementation of a Model 2 framework. You do not need to get involved with Struts in order to design your app to the Model 2 pattern. I think it's great to have frameworks that make writing complex web apps easier and more orderly (I've written one myself for use in all my web apps), but sometimes people get scared into thinking that they must adopt one of these frameworks to go the Model 2 route, and so they end up writing page-centric (so-called Model 1) web apps instead. I'd also go as far as to say that it's probably best to do some brute-force Model 2 work on your own to begin with. That way, once (or if) you do decide to adopt a framework, it'll seem less like black magic if you understand the pattern it is based upon. Another pattern to look for in understanding Model 2 is the Front Controller pattern. And rememeber, we're here for any questions you might have. hth, bear
Bear, I have a small question along the lines of your first answer above. Should there never ever be any database queries in a JSP page? For example, I am re-writing my app using the model 2 MVC and I have a template where the menu gets loaded from a database table. Here what I have done is to use JSTL and place the query inside my JSP page. In another page display_content.jsp > the controller checks which pages should simply load info from the database, it sets the categoryID, places it inside the request scope and then the display_content.jsp has a query and displays the content from the table. Again, I have placed the actual query inside the JSP. Would it better done in a different way? Thanks in advance.
The secret to creativity is knowing how to hide your sources.
Whenever you're serious about creating a web application, you'll want to steer clear of doing any work in the JSPs. The Model 2/MVC/n-tier architectures are very popular for a reason, that they make developing, understanding, web applications much much easier. In the long run, anyway - if this is just a quick and dirty job, then you probably won't see much benefit to taking the time to architect it "properly." But if it's a serious application, then separate any logic other than presentation from JSPs. Everything on a JSP should be for presentation purposes, or input/output, etc. But all the business rules and logic should happen behind the scenes, kicked off by a servlet. I'm currently developing an n-tiered application, and it's gotten to the point to where it will work with either JSPs/servlets or Swing! It's a very good design when you can use the same backend code for different GUIs Keep everything loosely coupled, and things will be organized much better. View(presentation) <- model(objects) <- controller <-> non web-specific java <-> database [ August 25, 2003: Message edited by: Phil Chuang ]
Everybody! Do the Funky Monkey! Like this tiny ad!