http://www.google.com <http://www.google.com/>
enter: MVC architecture -----Original Message----- From: Martin Gainty [mailto:[EMAIL PROTECTED]] Sent: Thursday, 10 October 2002 1:21 PM To: [EMAIL PROTECTED] Subject: Re: JSTL and Connection Pooling Greetings: What is MVC ? Thanks, Martin Gainty ______________________________________________ Disclaimer and confidentiality note Everything in this e-mail and any attachments relating to the official business of Laconia Data Systems (LDS) is proprietary to the company. It is confidential, legally privileged and protected by law. LDS does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of LDS. The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way. LDS can not assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference. _____________GMT-5___________________ >From: "Haseltine, Celeste" >Reply-To: A mailing list about Java Server Pages specification and reference >To: [EMAIL PROTECTED] >Subject: Re: JSTL and Connection Pooling >Date: Wed, 9 Oct 2002 10:41:50 -0500 >MIME-Version: 1.0 >Received: from mc5-f38.law1.hotmail.com ([65.54.252.45]) by mc5-s4.law1.hotmail.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 9 Oct 2002 11:07:59 -0700 >Received: from swjscmail2.java.sun.com ([192.18.99.108]) by mc5-f38.law1.hotmail.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 9 Oct 2002 08:47:06 -0700 >Received: from swjscmail1 (swjscmail1.Sun.COM [192.18.99.107])by swjscmail2.java.sun.com (Postfix) with ESMTPid F370222D9A; Wed, 9 Oct 2002 09:43:55 -0600 (MDT) >Received: from JAVA.SUN.COM by JAVA.SUN.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3417074 for [EMAIL PROTECTED]; Wed, 9 Oct 2002 09:41:55 -0600 >Received: from svr-mail.magtkt.com (unknown [208.1.247.29]) by swjscmail1.java.sun.com (Postfix) with ESMTP id 4D5DE485E for ; Wed, 9 Oct 2002 09:41:55 -0600 (MDT) >Delivered-To: [EMAIL PROTECTED] >Message-ID: >Sender: A mailing list about Java Server Pages specification and reference >Return-Path: [EMAIL PROTECTED] >X-OriginalArrivalTime: 09 Oct 2002 15:47:06.0912 (UTC) FILETIME=[1EF2E200:01C26FAB] > >I have to interject one comment to this discussion thread. Make sure that >you NEED to use an MVC architecture to complete the task at hand. I can't >count the number of times I have seen the Model II (MVC) architecture used >when it was overkill for the project at hand, and EJB's for that matter >also. Small apps that have a short life cycle(less than 12-18 months), >prototype applications (used to "feel out" the viability of a possibly >project or technology, or to do a "song and dance" for the CEO, CIO >management types), or applications that you know will very rarely be >modified (such as support of manufacturing equipment/medical diagnostic >equipment) do NOT necessarily need an MVC architecture. And keep in mind >that using an MVC architecture does increase your development time AND your >development cost, as the number of lines of code it takes to complete a >"stage or segment" in an MVC architecture application can be up to 33% more >than the lines of code it takes using the traditional Model I architecture. > >Examples of some of the types of applications I have worked on that did NOT >need the overhead of a Model II architecture include an intranet JSP/servlet >front end to support an industrial printing manufacturing line, and a >JSP/servlet GUI front end for medical diagnostic equipment. These types of >apps usually have a long life span, but are very rarely modified over the >life of the product, as they are much more dependent on the type of hardware >being used. Examples of applications that would probably require a LOT of >modification/maintenance over the life of the product, and that you would >want to consider using an Model II architecture include warehouse/product >inventory applications, web ordering applications, transportation >applications, and invoicing/billing applications. So make sure that you use >the type of architecture necessary to get the job done AND that gives your >client the "best bang" for their money. > >Just my 2 cents worth. > >Celeste Haseltine, PE >MTL, Inc > >-----Original Message----- >From: Hans Bergsten [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, October 08, 2002 8:54 PM >To: [EMAIL PROTECTED] >Subject: Re: JSTL and Connection Pooling > > >Joseph Ottinger wrote: > > Hans, I fully agree in that there are more than one side -- but I'd > > still stand by my statement to Troy, with a caveat in place. > > > > I have NO problem with Hans Bergsten, or Shawn Bayern, or James > > Strachan, etc., using the SQL tags. An expert can bend or break the > > rules, and generally does so when the situation calls for it - and > > because of expertise, you're generally sure that it's been done with > > logic and reason behind it. I've done the same myself. That said, I > > don't think someone who's willing to wonder if it should be done > > should do so, because the wonderment itself shows a lack of enough > > knowledge to make a correct choice. (I'm really not trying to be > > insulting to those who wonder - I mean, you have to start questioning > > methods SOMEWHERE. But let's pretend I'm speaking VERY generally, > > with the understanding that whoever's reading this is an obvious > > exception.) > > > > That's really my problem with the JSTL having SQL tags - instead of > > them being a tool chosen deliberately, they are being "blessed" by > > virtue of the JSTL mantle into being a commonly acceptable tool. I'm > > sorry; I realise JSP is fully able to serve as controller, model, > > *and* view, but I would hope that by now we'd realise that the first > > two roles aren't what it's suited for, and encouraging it in those > > roles is counterproductive. > >I don't want to start a long debate about this (I think the thread I >pointed to covers it pertty well), but I'll add one comment and try >to answer Troy's follow-up questions at the same time. > >Troy, the main reason many consider it bad practice to include database >access in a JSP page has nothing to do with performance, no matter if >you use the JSTL SQL actions or some other approach. It's all about >design and using appropriate abstractions to make the application >easier to maintain. If you include SQL in your JSP pages, you expose >the database schema in a part of the application that should not know >these details (the View in the MVC pattern). Or, a similar argument, >your using a technology (JSP) that is primarily intended for the View >(user interface) part of the application. > >I agree with Joseph that you should be aware of the drawbacks (an >application that may be hard to maintain and extend), but I still >think including SQL actions in JSTL was the right choice. If we didn't, >people who are not programmers but still like to use JSP to develop a >simple application would either use Java scriptlets with raw JDBC code >(and we've all seen the catastrophic results of a non-programmer doing >this), use one of the many third-party SQL custom tag libraries that >are available (better), or give up on using JSP altogether (sad); they >would _not_ learn OO design, how to program in Java, develop DAO, beans >and servlets. Isn't it better then to offer a simple set of standard JSP >actions that they can use? > >If you're enough of a Java programmer to know how to develop servlets >etc. you're hopefully also experienced enough to understand what can be >gained from using a more structured design, and you can make an educated >decision about whether to use or stay away from the JSTL SQL actions. If >not, your hopefully taking your job seriously enough to read up on these >things before you start hacking (and any good book or article point out >the pros and cons; at least mine do ;-). > >Hans >-- >Hans Bergsten [EMAIL PROTECTED] >Gefion Software http://www.gefionsoftware.com >JavaServer Pages http://TheJSPBook.com > >=========================================================================== >To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff >JSP-INTEREST". >For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST >DIGEST". >Some relevant FAQs on JSP/Servlets can be found at: > > http://archives.java.sun.com/jsp-interest.html > http://java.sun.com/products/jsp/faq.html > http://www.esperanto.org.nz/jsp/jspfaq.jsp > http://www.jguru.com/faq/index.jsp > http://www.jspinsider.com > >=========================================================================== >To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". >For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". >Some relevant FAQs on JSP/Servlets can be found at: > > http://archives.java.sun.com/jsp-interest.html > http://java.sun.com/products/jsp/faq.html > http://www.esperanto.org.nz/jsp/jspfaq.jsp > http://www.jguru.com/faq/index.jsp > http://www.jspinsider.com _____ Send and receive Hotmail on your mobile device: Click <http://g.msn.com/1HM1ENUS/c152??PI=44364> Here =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
