... and why is Struts MO BETTA?

Question

I've already coded most of my site with plain old JSP with taglibs. I structured an MVC model without the use of Struts. However, I figured I'd better go ahead and learn about the framework. You know how managers and recruiters are about matching their silly job requirements these days. It's better to have a buzzword on your resume than it is to actually have 20 yrs experience. But lets not get me started on that!
So I went out and bought myself a book on Struts. After a somewhat brief intro, I've come to the conclusion that I would have to write just as much code in a Struts environment as I have already done with Vanilla JSP, plus deal with yet another layer of abstraction. So I figure that Struts advantage must be in the organized structuring, maintenance and perhaps portability of code. Why not just write the darn code ... already!
I know this is going to induce a little politics into the frey, but I just have to ask ... Am I missing something here? I know my opinion might be a little premature, but right now I don't see the "BIG DEAL!"
Don't get upset though - I might yet become a convert!

Answer 1

Yeah, I worked for a company that migrated to an
n-tier architecture from their old legacy systems in
the late 90's. They changed the name to n-tears!I'll have to remember that. ;)
I once thought that Oracle had it right. Your view
should be used to send insert, update, delete and
query requests to the backend. As for the middle tier
and business logic, well thats what database triggers
and stored procedures are for. I guess that's the argument - render unto the middle tier the business logic, and unto the database persistence logic.
Even Oracle has gotten into the act early. They've got a J2EE app server running inside the database. You can write Java stored procs. Of course if your database goes down so does that app server, and visa versa. You end up assuming that the data source is only used by J2EE apps. If that's not the case it might not be a good design.
So whats all this
middle tier business? Most of these middle tiers
where written by third-party vendors and did not
integrate well with any of the other tiers. I heard
all the brew-ha-ha about how this mutliple tier setup
was supposed to reduce network traffic and reduce
response times and make esspresso for the staff while
it was at it.Which vendor was that? I gotta get me some of that! ;)
You guessed it! It didn't happen. First of all I
never understood how replacing a query being sent from
a heavy client with one being sent from a middle tier
was supposed to reduce network traffic. Unless of
course you put the middle tier on the same server as
the database. Most of the time they're separate, of course.
To me a query is a query and a result
set still has to be processed at the DB server and
packets have to be sent to the requester regardless of
what tier the request came from. Response times got
painfully slow in spite of all the hipe about how much
more efficient adding the middle tier was going to be.Indeed, I agree. But the fastest database query you can make is the one that doesn't go out over the network. Caching on the middle tier can help speed things, no?
End the end, my little "FAT" client Sql*Windows blew
the doors off of this flash bang, revolutionary n-tier
system and ended up saving my manager his job.I can't argue with that. Sounds like you did a good job.
Even M$ is embracing this model with their .NET framework. Are you saying they're wrong to abandon their client/server fixation?
I've always found the middle tier in the so-called
n-tier architectures extremely lacking. That is until
Java came along with its beans and tagslibs. That I
like.Maybe the first implementations that you were involved with were just poor first attempts. Do you think it's better now, in your experience? Can all these companies be fooled for all this time if it's worthless?
It seems to me that it's getting worse if that's the case, because service-oriented architecture will simply codify the distributed nature of the middle tier. Martin Fowler's Rule of Distributed Architecture will be broken forever when this becomes widespread.