Jsp Is Totally Inadequate

(note: I moved Costin's contribution here from ModelModelViewController, so as to keep that page, and this one, focused on their title topics. -- RandyStafford)

Or, instead of worrying about names, it is time for the J2EE /JSP community to recognize that MVC or MMVC or whatever you want to name it is totally inadequate for the kind of web based, database driven applications. It's time to go back to basics and PutTheDamnDataOnTheDamnScreen?, or otherwise Java will suffocate slowly but surely under it's own "architectural" weight. As I see it now, it becomes economically unsustainable to develop these kind of applications using MMVC paradigm: too much lines of code, too much unnecessary OO philosophy, too many developer hours. No objective metric can justify the likes of PetStore approach.

-- CostinCozianu

Ever-provocative, eh, Costin? ;) I've found MVC-based, JSP UI architectures to be perfectly adequate for the last six J2EE apps I've delivered. I agree with you that getting the most functionality for the least code is one of the objectives - and that is one of the primary intents of MVC philosophy. As for PetStore, I can't speak to it - I've never studied it. If you want to look at good examples of MVC, download VisualWorks and study the implementation of the system tools, like the browsers, etc. Best Regards, -- RandyStafford

Well, Randy, I didn't say that you can't make it work. I've done it too, but I found myself wasting way too much time and unnecessary lines of code on pretty stupid things. Unfortunately, there were not too many alternatives at the time. But let's get down to a very simple system: a personal agenda, with only one table in the database, you have to be able to insert/update/delete entries as well as search for them. I take DelphiLanguage, you take VisualWorks or your favorite Smalltalk IDE and use the MVC architecture. With DelphiLanguage, it takes me close to 0 lines of code (a negligible quantity anyways), with validation and everything included. Likewise, if you want to put it on the Net, I can do it to close to 0 lines of code.

We can also look to a slightly more complicated application like a basic general ledger type of stuff. Again, you can do it in close to 0 LOC, or you can waste time declaring object models, entity beans and controllers and views and mappings between the relational DB and the object model, and in the end, you'll have an application no better than mine, with an order of magnitude more effort. What is necessary to write a relatively more complicated thing like a Smalltalk object browser, where you can have several views, events coming from multiple windows, and notifications needing to be sent to several windows, is way overkill for a web based application where the nature of processing is strictly linear: request->processing->response. On the input, the problem is how to connect the request to the desire processing, on the output, the problem is what's the easiest way to get the data on the page. J2EE offers inadequate answers to both these problems. -- CostinCozianu

Whatever, Costin. I'm not going to get into another one of these things with you where you tell me everything I've ever done in my software development career was wrong, and where you try to convince the world that your opinions have more merit than the collective experience of dozens of very brilliant and generous software people who've developed and shared their insight over the course of the last three decades. Good day to you, Sir. -- RandyStafford

Randy, it is preposterous for you to invoke the collective experience and all the other blah, blah. As if you didn't know that different great software people have done things very differently over the course of decades and nobody has yet arrived at truly magnificent results. So there is absolutely no collective experience on what is the way to build software. Other than that, you should've known by now that I didn't bring any truly original and personal idea on wiki, including on the current subject. If you didn't know, I'm sorry to say but you need to read more.

So it is a fallacy to juxtapose the collective exceptional wisdom of truly great, creme de la creme software people, with the personal ramblings of CostinCozianu. This is at best misguided if not just plain bs. Cheers, Costin.

Wow, for once I completely agree with Costin. Quick, somebody check to see if hell has, indeed, frozen over. Joking aside, Costin does raise a point I find myself pondering frequently: Why do we complicate the request/response architecture to such a horrid extent? In all seriousness, the web application model maps almost 1-to-1 to a 3270 or 5250 model. What are the predominant languages in these environments? COBOL and RPG. Why? They excel at moving data from one place to another, because that's all these applications do.

Indeed, the sad fact is that 3270 and 5250 terminal applications actually tend to work better than web-applications because IBM coded in at least a minimum level of input validation logic into the terminals themselves. In the case of 5250, I can display sub-files (scrolling lists of stuff), which is a terminal supported facility, not a hack as in the case of 3270 or web applications.

I hear from users all too frequently that web applications don't provide the functionality they had on the mainframe, AS/400, or fat client application the web client is supposed to replace. Am I saying one is better than the other? Not necessarily, but I am saying that the mainframe/AS/400 model of development is indeed simpler. They require fewer lines of code to accomplish the same tasks and users tend to be happier using them.

While fat-client GUI applications require more code than a respective 3270 or 5250 application, they at least meet user expectations. Before someone says that thin-clients can, indeed, include complex client side validation, I would say, "You're right." But - and this is the clincher - good or bad, there is only one predominant browser on the market today: Internet Explorer. If I'm going to all of the trouble to write JavaScript (yuck) and muck with the DOM that IE provides, why not just write a VB (or Delphi as Costin says above) or a VisualWorks application and get it over with?

Besides being the current fad in "client side" application development, I don't see the advantages of web apps (this includes J2EE), and I've written dozens.

Oh yeah - as for the centralizing aspect of web-applications, I have four things to say: Mainframe, AS/400, Windows Terminal Server, or X Windows. Each one of these works better. -- JeffPanici

I find myself moving towards simpler things and simpler architectures in the last few years. In several of our applications, we are using JSPs merely as a pass-through to a server action class. The value of the JSP is nothing more than not having to mess with a web.xml. That is sufficient for me. The JSPs are one-liners or very few lines if some parms have to be moved around. I apply the same to talking to databases. While I create some kind of packaging to keep database code separate from business logic, I avoid database frameworks or persistence frameworks. I just have no need for them and they unnecessarily complicate applications. -- MikeCorum

I agree too, I've spent a number of years working with MVC architectures and to be honest, the benefits are not worth the effort - for example: we've never ever replaced a GUI but left the model/controller elements as they are. Never. Not once. And the amount of effort in building the MVC code significantly outweighs that of building the business tier. I'm not suggesting it doesn't have a use. In an application such as say a word processor, i.e. one that is likely to be developed for years then there's probably an advantage maintenance-wise, but I guess I think there's a cost/benefit thing going on that I don't think pays off for most small applications.

Strangely, Jeff's point above echoes our situation at work in that we can't match the estimates of the guys doing the 3270 screens, not because GUIs fundamentally take longer, but because we're forced into a even more complicated than usual implementation of an MVC pattern - so ultimately the clients don't get what they want, purely because the guys doing 3270 stuff don't have to stick to a design pattern (at least one not invented in the past 30 years :)

Having said that, isn't logic running on the mainframe, sending a message back to a 3270 via MFS a form of a MVC pattern?

Is it MVC like Smalltalk MVC? No. Is it MVC like the currently popular web-page to CGI "controller"? Mostly. There are things, obviously, that one can do in a web browser than one cannot do with a 3270/5250 terminal. However, much of the "client side" functionality is already built into the 3270/5250 terminal itself. That's why I drew the anology in the first place. At most, a web browser puts a pretty face on what was once green, blue and white. At worst (as seems to be the common case), it complicates what those character based systems do best: put the damn data on the damn screen. -- JeffPanici