Manning's Struts in Action

cpfeifer writes "Building browser-based java applications has involved a mixed bag of server side technologies (servlets, JSPs), client side technologies (HTML, Javascript) and frameworks (webmacro, Struts, Taglibs, Velocity). As these technologies appeared and matured, "The Right Way" (tm) to build web applications evolved to be an application of the classic model-view-controller pattern." Below is Craig's review of Struts in Action, a book which attempts to illustrate a successful path to making sure that web applications are designed the right way.

Struts in Action
author	Husted, Dumoulin, Franciscus, Winterfeldt
pages	630
publisher	Manning
rating	(11/10) it goes to 11
reviewer	Craig Pfeifer
ISBN	1930110502
summary	More than just a book about how to use the Struts framework, covers the best practices of web application design and development. If you are building a java web application of any appreciable size, YOU NEED THIS BOOK.

What's Needed

So it is generally acknowledged that using the MVC pattern is the proper way to build web applications, but with the large number of technologies and frameworks it can be a long road to figure what is the best solution for your application. What we need is a book that covers the best practices of web application design and development from both a technology/architecture perspective, and is written by a few folks who have deep understanding of the underlying problems of building robust web applications.

That's what I love the most about this book, it doesn't just talk about how to configure and develop with Struts. It's a web application manifesto. Anyone can write a book about how to use Struts to build a web application. That's not the point. This book is ~8 people-years worth of first-hend developer knowledge (4 authors x ~2 years of working on the Struts project) condensed down into 630 pages. It doesn't just teach you how to use Struts (and Velocity and Taglibs and Tiles), but why you should use them. That's the most important thing this book has to offer. If your project is looking at using Struts & other Jakarta technologies, you need this book. If your project is currently using Struts & other Jakarta technologies, you need this book.

What's Bad?

The Velocity coverage is pretty light. If you are more comfortable building logic with a quasi-shell script language instead of using markup tags, then you should look to the project's documentation for further reference before embarking on a prototype. The Jakarta Lucene project, is touched on in the sample application they build, but are left as an exercise for the reader to investigate. While it's good to bring in related technologies to flesh out your sample apps, you have to be careful not to get sidetracked from the primary topic. You could easily write several books about the other components developed by the Jakarta project.

What's Good?

The best part is that the 4 authors are all Struts authorities (one Jakarta project manager, 2 Struts committers, one principal consultant), so they know Struts and the other Jakarta web frameworks inside and out. More than that, these guys have been solving the problems involved with web applications for several years now. They have deep experience in the patterns and best practices of building robust and flexible web applications, and this book passes on their experiences to the reader.

So What's In It For Me?

With this book and a little bit of effort on your part, you will be a competent Java web application developer. With a little bit more effort, you will become a Java web application architect. It's worth the extra effort. This is a tremendous book that will set the standard for web application references and will continue to be useful for years to come. It reminds me of the first Manning book I read, Neward's Server-Based Java Programming in terms of it's scope. approach and usefulness.

---

You can purchase Struts in Action from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

MVC to all who say "I just write..."

[MosesJones]

MVC is about design, its about knowing that your application will be maintained by other people. Its about seperating the various elements so multiple people can work on your project. Its about ensuring that elements are re-used effectively so testing effort is used more effectively.

MVC is about projects that work well. So to all those people who just "hack it together on my own", please remember that there are some people out there who do this for a living on sites and system that will still be maintained in 5, 10, 15 years or even longer. That is why you choose MVC, because you realise that Go-Live is only a small part of TCO.

MVC is great, and MDA is even better because it uses similar patterns at an even higher level.

Design is good, design works, patterns work. Just because you can "write 1,000 lines in a day" doesn't mean that in 6 months time even YOU will be able to maintain it. Don't knock it until you've been on a project with 10 people where they all thought they could do it their own way.

Be an engineer, not a script kiddie.

The thing about MVC

[dmorin]

This is probably off topic, but I just got off the phone with somebody talking about MVC. In my experience thus far, MVC often falls victim to "Yeah, it's a good pattern in theory, but in implementation it's going to make my life harder by forcing me to separate things that I don't technically have to separate." When people create their own stuff from scratch I think that they often get close to MVC but don't fully realize it. We had this problem with Struts in our platform. We have a homegrown forms library on top of a proprietary app server. When the time came to rewrite it in open source we started by looking at Struts and decided that Struts added too much complexity, that we could port what we had more directly and get running faster. Of course, after doing that, we all knew that Struts was where we wanted to be long term so we started designing a plan for getting it in there.

Random MVC joke. Saw a cartoon in a Java mag once where a project manager is saying to his engineers, "For this part of the user interface we can either go with a Swing applet, or ActiveX control." Engineers all chant "Swing!Swing!Swing!" Project manager says, "If we go with Swing, it will require substantial work with JTree." Engineers all chant "ActiveX! ActiveX! ActiveX!"

:) Duane

Struts and MVC

[giel]

IMHO using Struts (and web applications in general) you cannot build true MVC based applications.

The MVC model defines more communication options and knowledge between objects that Struts is able to provide. MVC is event driven, a Struts application is driven by actions (post or get).
The Structs framework, as I understand it, in general works like this:
- A http request is sent to some dispatch. This dispatch converts the request into an 'action'.
- The action is executed and returns a new request, either for a JSP or some other Template to be rendered or a new action.

Using MVC a view contains components that have corresponding controllers. The view is usually a predefined API to a collection of widgets (like AWT, Swing, etc.). The controller is built of events bound to the widgets.
Struts calls the jsp's the view, the actions the controller and the back-end or business logic you define the model.

However MVC allows the model to interact with the view, and there is no way you can be sure you will be able to do so with a web page, because HTTP only supports polling and not pushing if you want to keep things browser independant.
Well that's why I would not dare to say Struts implements MVC for web applications, but I must admit it provides a very nice framework.

If you _want_ to do it youself that is...

[jaaron]

I don't think anyone will claim you have to use third party applications to create an MVC-based web app. In fact, if you look at the core of Struts, it's rather simple (which IMHO is what makes it so nice). Any decent java developer could write something similiar and many have.

I think the point is, why go it alone? When you can have hundreds of developers all working on and testing the same framework you end up with a lot more features and much more stable code. Sure I could write my own controler servlet (which is what Struts mostly is), but personally, I don't really want to have to write up the validation scheme, the internationalization features, the tag libs that make it easier to work with, and so on. With Struts, it's all there to begin with and it works. Additionally, when I hand over a Struts project to another developer or team, I can just say, "Oh, it's Struts based" and immediately they have access to host of documentation and an entire user community for support. I don't have to sit down and teach them how my special MVC magic works.

I could go on, but I really find using a popular stable project like Struts has a lot of advantages. And yes, Struts is not perfect. There are lot of other good frameworks out there. It just so happens that Struts is very close to how I and my coworkers developed web apps to begin with, so the convertion factor was minimal and the gain was incredible.

What about the bigger picture?

[smagoun]

Structs is cool, but it's just a small piece of a much bigger picture. There are many cases where a simple 1- or 2-tier app is perfectly adequate, and basing your app on Struts is appropriate for that. Those are rightly called "web applications."

If you're building an enterprise app, however, basing your app on Struts (or any other "web application" technology) isn't a good idea. Why? You wind up mixing your app's functionality with its implementation. Using an MVC framework like Struts alleviates this problem to a great deal, but when it comes down to it you still have a big pile of servlets that does everything from database access to presentation.

That approach isn't scalable, it's not adaptable to different technologies (there's a new webapp framework every week, it seems), it's not easy to integrate with other applications, and so on.

What's really needed is a way to define an application independently of the implementation details. Once you've defined the application, you can generate whatever interfaces it needs - like a Struts UI, an EJB persistence engine, etc. This is where my shameless plug begins: check out the Sandboss [sandboss.org] project for a way to define your enterprise app without being chained to a particular implementation detail like Struts or EJB.

While the techniques used in Sandboss are designed for the enterprise world, they're useful for web apps, too. I think it makes much more sense to over-engineer an application than it does to under-engineer it; overengineering takes more time up front but saves you 10x as much or more once development starts, since the well-don overengineered solution is more flexible and capable of responding to marketing's feature of the week. By picking Sandboss you get the best of both worlds - a robust framework where someone else has already done the engineering. You just define your app, and bam! Persistence, communication, control, the UI are all done for you.</shameless plug>

This is actually a valid question

[jaaron]

It seems to me that for 95% of the web sites in operation, by the time you finish building the MVC app in Java using Struts you could have coded it 3 times in PHP or Perl?

This comes up from time to time and I think it's a good question. There was an good discussion about this on the jakarta-general mailing list. It's a long thread, but if you'd like you can start reading at this [mail-archive.com] point. The best part of it I think is this response by Jon Scott Stevens:

Java is not the fastest technology to develop in, however, it produces the best code for the long term.

PHP is the fastest technology to develop in, however, it produces the crappiest code for the long term.

I develop Scarab in Java because it is going to live far longer than I do and needs a solid base to work from.

I develop my bar's website in PHP because I just needed to get the job done quickly and was not concerned with code quality.



Remember, PHP originally stood for Personal Homepage Parser. Java's web application technology was designed from the start to be a solution for a large "enterprise" class web site. You can do more with Java but you definitely take a hit in initial development time. Personally I feel that in the end, Java is easier to maintain and extend (but you may disagree).

By the way, Yahoo! didn't go with Java because of the Java threads implementation on FreeBSD. It didn't have anything to do with the merits of the java language. (See Why not JSP, Servlets, or J2EE? [yahoo.com])

Re:MVC to all who say "I just write..."

[drewmca]

I agree strongly. I think that people fail to realize, from management on down to the trenches, that the real cost of software development is in maintenance. If you write a really nice subtle piece of code that saves processor cycles but is hard to understand, any performance gain (or points you give yourself for programming skill) will be completely offset by the time spent by other developers or you trying to figure out how it works a month or a year down the line. Very little code goes through its lifetime unaltered; things get added, removed, extended, etc., all the time because of business pressures. The harder this is to do, the higher the cost. A perfect example of this is in variable naming. So many people I've worked with continue to use cryptic variable names like "chks". Wake up people! We no longer need to deal with the limitations of computers from 10 years ago! We can actually use long variable names without a performace hit! Isn't it about time our programming style changed to reflect that? Wouldn't it be easier to have a variable named "checks" so that other people could understand what was going on in the code? Or so they wouldn't confuse it with another variable "checksum", for example? Of course, there's a fine line where too much design slows things down. You can't overengineer. I like a lot of what the XP people say about this, especially with the one-two punch of strict unit testing and refactoring.

Re:Perl? Just use PHP

[Anonymous Coward]

Yahoo is moving to PHP solely because they depend on FreeBSD servers, and Thread/Java support on FreeBSD is week at best. (Trust me, I'm at a job where i'm forced to deploy Java on FreeBSD).

If you've ever worked on an app for an IT Department that is rather large, you'll understand quickly why companies use a programming language instead of a scripting language. There are programming methodologies, frameworks, toolsets, and other advantages that make enterprise level application development in Java worthwhile.

PHP is great for small standalone apps when the problem domain is finite, and no legacy systems are involved.

When you need to integrate AS/400 systems, FileMaker databases and connect to credit card billing systems, you'll see that you'll go places that PHP can't take you.

I don't want to sound lame and say trust me, when you've done large-scale application development for an IT department of a good size company, you'll figure it out.... but that's really the case.

I use PHP apps like phpMyAdmin as a regular part of my development, but Java provides the discipline and legacy integration that scripting language can't provide.