Beyond MVC: A New Look at the Servlet Infrastructure

Discussions

News: Beyond MVC: A New Look at the Servlet Infrastructure

  1. I've written an article summarizing my concerns about the "Model-View-Controller" design pattern and how it is being misapplied to Servlet framework projects to the detriment of the entire J2EE community.

    Read the entire article at Java.net

    A brief summary:

    "This article is the first of two that examine in depth the origins of the Model-View-Controller (MVC) design pattern and its misapplication to servlet framework architectures. The purpose of this first piece is threefold. First, it attempts to provide an accurate description of the problems brought about by MVC in servlet middleware. Second, it suggests techniques and strategies for coming up with a new design, one better suited to the needs of servlet infrastructure developers. Third, it offers an example of a completely new, nonderivative pattern we might use moving forward."

    This has been an extraordinarily difficult topic because so many people have worked hard to successfully implement MVC architectures in servlet frameworks and because the pressure to be buzzword compliant is so intense in our crowd. Despite this, I've been able to treat the topic methodically and rationally and I think my conclusions are worth consideration.

    This article is especially written for the developers of Struts, Webwork, Spring, and all the other projects who are trying to solve this common problem, but who for many different reasons have splintered and become entrenched around their respective technologies. I see a potential way out of this state, a way we could reunite and make IBM, BEA and Microsoft sweat bullets.

    So please, I encourage you to lay your convictions aside for a moment, place them and the article respectfully on ice and treat it methodically and rationally.

    And also bear this in mind: I'm no armchair pundit. I've got real, functional code to back up my assertions, and Part Two of my article will explore that code and its architecture in great detail.

    --
    N.

    Threaded Messages (52)

  2. MVC or is it...[ Go to top ]

    I am most happy to agree that most MVC implementations that exist for the servlet/jsp platform have problems. But the question is: Where is the problem? And of course: Is it MVC? In my opionion, frameworks like struts etc. are not MVC in the sense a typical fat client ui is. They never can be in the sense that the controller talks to the model that notifies the view of the change. Most "MVC frameworks" are in fact state machines no more, no less. And the stateless communication protocol together with a server side state machine create all the more problems. And I am not starting to complain that the crappy and utterly foolish "servlet controller" approach outright breaks the security infrastructure of the servlet platform.

    Therefore, I would assume we do not need what Alex is proposing but quite the opposite: Standalone, independent and interacting frontend and backend components that can be assembled inside the standard jsp/servlet/ejb layer without the need for some "workflow engine" or anything like it doing the work.
    I think that JSF (if we will live to see it that is) can provide the frontend foundation of such an architecture (see my own efforts at http://www.iternum.com/i3ui/demos.jsp). Databinding objects etc. can provide something similar for the backend components. But please no "workflow infrastructure".
  3. MVC[ Go to top ]

    If it ain't broke - don't fix it.
  4. If everyone thought like that, we'd all be living in caves with stone axes and no beer.
  5. MVC has been discussed, developed, extended - you name it. There're a number of diffirent implementations to choose from to suit all.

    It's a pattern, thats it! If it doesn't work for you choose a different one.
  6. Nice and Easy[ Go to top ]

    I'd like to be able to define and app in the style following;

    <app>
      <states initial="Login">
         <state name="Login">
           <transition>
             <to>LoggedIn</to>
             <condition>Login.LoggedInOK</condition>
           <transition>
         </state>
         <state name="LoggedIn">
           <transition>
           <transition>
         </state>
      </states>

      <conditions>
         <condition name="Login.LoggedInOK">
         </condition>
      </conditions>

      <views>
        <view name="Login">
           <component name="LoginPage"/>
        </view>
        <view name="LoggedIn">
           <component name="StartPage"/>
        </view>
      </views>

      <components>

        <component name="LoginPage">
          <file name="Loggin.html"/>
        </component>

        <component name="StartPage">
          <file name="StdHeader.inc"/>
          <template></template>
          <script></script>
          <class></class>
          <xslt></xslt>
          <literal></literal>
        </component>
      </components>
    </app>

    All nicely decoupled, and easily verified for state links/unreachable pages etc.
  7. JSF?[ Go to top ]

    Is this derived from a faces-config.xml of a JavaServer Faces app?
  8. I've been a software engineer for quite some years and have been involved in several Java/J2EE projects over the years. For those of you, who started their career before the Java hype, this article speaks out what many have been feeling and thinking about the application of MVC to the servlet architecture (among other J2EE ideas).

    I tried several frameworks (incl. my own) that each attempted to address the issues. All of them turned out to be more a burden than help. My experiences match those of the author and I agree that the servlet architecture is not well suited for mvc or that mvc is not well suited for servlets.

    In applying the mvc architectural pattern (among others), we usually "bend-over" to make it work instead of thinking that something could be inherently wrong. Our community has a virus called "buzzwords" that seeps into it more and more. I haven't seen a single architect in years who used any of the established architecture analysis methods.

    Well, complaining is easy, I haven't found the silver bullet by myself yet. Each system is different and deserves a separate look at. Teaching the community of J2EE architects/developers patterns can be dangerous and easily turn into antipatterns, if they don't take the time to evaluate and apply them correctly.

    This article is well written and I think, very founded. I would recommend, reading it. I'm looking forward to part 2 and 3!

    Janek
  9. I agree. Alex finally got the point. I only have a few years in enterprise development and even less years in J2EE but I feel that it is indeed complex, but why? beacuse WE make it unnecessarily complex.
    Since I learned about patterns, distributed computing and all the J2EE acronyms, I started wandering in a labyrinth of posible solutions. As Alex stated in the article "There is no silver bullet", there will never be, but some common sense in the community would be greatly appreciated.
    Even the need for a better solution post-MVC is problematic since others have started to see development the way we see it, take .NET and PHP for example.
    Both technologies have adopted many of the J2EE principles, patterns, and such just now when the J2EE community is screaming for new ways to reduce complexity and better the quality of our work (AOP for example).
    I think, as it has been said in this columns many times more, that we really need to review some of our practices. I am looking forward to part 2 and 3 of Alex's article, great work, recommended.
  10. Maybe time for a paradigm shift?[ Go to top ]

    As I'm quite involved into GUIs for OO systems, I also know the drawbacks of MVC. Although MVC is a proven design even for large systems, I always agreed to the opinion that MVC is breaking the OO principle of encapsulation. Then I came across Alan Holub's article at JavaWorld at http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox.html

    I found this idea fscinating and also quite applicable if you don't need more than one view per model. Anyway I never used his Visual Proxy pattern in real life as the team decision always favoured MVC because it's a proven design. I'm not so familiar with java servlets but what do you think: is it possible to give the Visual Proxy a chance in the context of servlets?

    Olaf
  11. Re: Maybe time for a paradigm shift?[ Go to top ]

    is it possible to give the Visual Proxy a chance in the context of servlets?


    Yes. And some people (us) have been using it quite successfully. (although we prefer to term it PAC)

    It is most useful when you have polymorphism, e.g. a catalogue with different items of common types in it. Then it shines, and shows well the limitations of the basic MVC concept. In most other cases plain MVC would suffice.

    In terms of use in the servlet space, I think you can use it with most framewors, although I personally prefer Tapestry because it allows you to implement the concept nicely without having to mix Java and HTML (but that's another topic that has been discussed before).
  12. Groovlets[ Go to top ]

    I'm all for getting rid of this Java/HTML in the same file shite. It's driving me nuts. I'll probably use Groovlets (groovy servlets) for all my servlet needs from now on.

    I love Groovy.
  13. Round Peg, Square Hole[ Go to top ]

    Browsers and server-side HTML generation/presentation are great for "browsing". Browsers are ideal for surfing, reading docs, shopping and filling out forms, etc... Where most of these "mvc" frameworks begin to breakdown is when they go outside this box and get into more complex and rich application type behavior (things better suited for the traditional fat client).

    Rich applications should not be built using the server-side HTML generation paradigm anymore. There were not a lot of options when the net came into being but now there are. Using technology like jnlp to network the code on the fly and having the app communicate using web services with the web server is all possible now.

    We now need frameworks geared toward networked applications and not frameworks that spend their lives generating HTML and trying to feebly keep a browser's state in sync with the backend.

    -Sam
  14. I agree. You read the wrong article ;)

    You might check out my "other" piece, the Java.net blog from a couple of days ago on the presentation topic (here). I'm actually working on a client-side Flash framework that plugs into an open source app server and uses XML (a la jelly / MXML) to drive presentation logic, and also allows designers to write pluggable skins for the UI components. This is basically what Flex is doing, and what Lazlo has done.

    I started a project a long time ago (Jammies) with a good friend of mine to do this sort of thing. He was going to spearhead the effort, but he didn't really need a rich thin client badly enough to write one.

    (shrugs) Cabinetmakers. Whaddya gonna do?

    But now *I* need it, so I'm thinking along those lines again. ;)

    --
    N. Alex Rupp
  15. Macromedia's article on Flex and Struts[ Go to top ]

    Macromedia Developer Center just posted one article on how to provide a Flex Front End to Strus Applications.
  16. Web Continuations[ Go to top ]

    After playing with numerous web application frameworks, I've come to the conclusion that what most of them (though, not all) are missing is support for continuations. (more to follow, seems that the serverside thinks i've invalid html in here somewhere).
  17. https unsupported protocol[ Go to top ]

    Hmmm... seems that the serverside can't handle https urls (and dev.java.net redirects to an https url for http://rife.dev.java.net)
  18. it couldnt be a better endorsement to Rod Johnson's Work!!!
    Go Rod, Go!!
    In Rod, we trust!!!
    ----------------
    this is an extract from the shock's FAQ!! Looks like J2EE community is looking forward to a much better developing time!
    -----------

    How does Shocks compare with Spring?

    That remains to be seen.

    Shocks is younger than Spring and is not as mature, but it does contain some features which Spring does not.

    Shocks can transport application metadata and Action classes between ClassLoaders in a servlet container and at the same time allow the application workflow to be managed using JMX. It does this by taking advantage of the JMX microkernel which lies at the heart of the Geronimo and JBoss application servers and the Tomcat servlet container. This allows web applications to be broken into small modules. A single web application could therefore be composed of hundreds of .war files.

    Making your application more modular and reducing the friction associated with integrating changes into the application at runtime means you can shorten development cycles and deliver features more often. No more four-month codeslides.

    Being able to manage the application at runtime means if you introduce a change to the workflow and it doesn't behave as you expected, you can roll back to a previous version of the workflow. We're working on adding that feature.

    Although there is a lot of overlap between Shocks and Spring, that could turn out to be a good thing. We probably have a lot to learn from them, and perhaps we can teach them a trick or two along the way.
  19. Web Continuations[ Go to top ]

    This is due to Java's missing support for continuations (and thus, all the web application frameworks that do have continuations either rewrite the bytecode e.g. rife and ACTC or use some other language e.g. cocoon) none of the solutions are as neat or as widely used as they could be.

    most of the current generation of web applications are _not_ stateless - consider the last time you wrote a web application without using the session. application frameworks like struts etc. are forced to mimic continuations with struts-config action mappings and using the session as a variable noticeboard which is the exact equivalent of using only global variables and goto statements. and it's not even as neat as using BASIC (no gosub's for example).

    Now to the article. N. Alex Rupp is essentially plugging Shocks (shocks) - not a bad thing mind you - and by the look of it, it is a good second generatation web application framework but I don't believe it solves the problem of state management in a web conversation.
  20. Web Continuations[ Go to top ]

    I think the author of the article is trying to create some ground probably for the Shocks framework.

    The article definitely was enjoyable reading. Good job.
  21. Web Continuations[ Go to top ]

    Actually itÂ’s possible to use continuations in pure Java using framework called ATCT.
    Here you can find an example how it could be used in web applications.
     
    Serguei Mourachov
    www.velare.com
  22. Web Continuations[ Go to top ]

    Actually it’s possible to use continuations in pure Java using framework called ATCT.

    It would be nifty if someone hacked BeanShell to do the same -- and be open source freeware. I've considered doing this BeanShell hack for Cocoon, but couldn't bring myself to contribute to a server framework who's original aim was thin clients.
  23. Source archive is broken[ Go to top ]

    After reading your interesting article I tried downloading the source but
    unfortunately the tar archive seems to be broken. Tried it several times from
    different servers, always got a broken archive.
    Could you please fix this because I am really interested in your approach and
    I think everybody should have an open mind for new ideas.

    Currently I am using Spring and I am really happy with it.
    What all frameworks I used in the past including Spring are lacking is a powerful workflow component. Your approach seems to go into this direction.

    jd
  24. Source archive is broken[ Go to top ]

    Owner@VASKOT /cygdrive/d/tools/shocks
    $ dir
    shocks_1_0_0_alpha.tar

    Owner@VASKOT /cygdrive/d/tools/shocks
    $ tar -xvf shocks*
    tar: This does not look like a tar archive
    tar: Skipping to next header
    tar: Archive contains obsolescent base-64 headers
    tar: Error exit delayed from previous errors
    -----------
    looks like the tar file is not a good one. I could download it though.
  25. Re: Source archive is broken[ Go to top ]

    I'll do what I can--thanks for the heads-up. I was planning on shipping alpha-2 release tonight anyhow ;)

    Also, please bear in mind that right now the project is in transition--I'm moving it to codehaus.

    Cheers,
    --
    N. Alex Rupp
  26. Sorry about the broken tar, Jagan.

    I'm not sure what happened there. I've posted an alpha02 release and tested it to make sure it works. You should be able to "cd build" and "./build.sh" if you've got ant installed and the properties file is correct. Otherwise, if you need a snapshot, you should be able to download that directly from the SF page.

    This is the last release I'll be publishing at SourceForge, because the project is moving to codehaus.

    Hope this helps,
    --
    N. Alex Rupp
  27. Shocks alpha02 release now available[ Go to top ]

    The archive was just gzipped twice..
    After gunzip rename again to [file].tar.gz and then gunzip again
  28. Webwork 2[ Go to top ]

    I'm not trying to plug webwork2 here, but it seems that the author is a bit too biased about promoting his own framework (which looks nice, by the way) and forget to tell us what's really bad about the existing ones.

    Now, take webwork2 (and xwork), forget about the MVC buzzword and let's look what we can do with them.

    1. XWork actions input is totally abstracted by the value stack. Each action's input could come from any source. This could easily be related to the "DataSource" component referred in the article.

    2. XWork actions are modular, self contained and sure able to be as fine grained as you need them.

    3. Action chains provide a nice and clean way to define your workflow. Select your actions and chain them together in the order you want.

    4. XWork and Webwork2 are defined by interfaces, so you can plug your own implementation for every part of the system.

    5. Interceptors (and interceptor chains) provide a nice way to define cross-cutting concerns.

    To me, webwork2+xwork form a quite good framework that implements all the requirements and concerns the author expressed in the article. There's no need for a real pradigm shift and snubbing the current offerings. If you look at webwork2 without caring for the MVC buzzword you'll find that's a really nice framework for server side applications.
  29. I agree--mostly[ Go to top ]

    So far, I think everyone's been very thoughtful about their feedback, and I'm grateful for that.

    As to your comments about Webwork, I agree with you on most of your points. But there are substantial differences in the way our two technologies work. Those differences will become more clear as I complete more documentation and as the project moves toward a gold release.

    For a while I tried to incorporate my ideas into XWork/WW2. Unfortunately, at the time they didn't seem interested in my focus on JMX, because at the time it would only have worked in JBoss. I needed to do stuff that WW2 just wouldn't do, and we couldn't figure out how to add my stuff into theirs. One of them took me aside, told me to take a hike and write my own. And they moved ahead, and I did too.

    And it was a good experience. I learned that code speaks louder than words, and don't blame them for the brush-off. Lots of people talk about fixing code but never step up to the plate. It's the most annoying thing in the whole world.

    Now of course, things have changed. I can develop in Geronimo. And word on the street is that JMX will play a bigger role in the proprietary app servers who are seeing the benefit of more modular design and JSR-88 extensibility.

    Please don't think I'm "snubbing" the OpenSymphony guys. They're a fantastic and energetic bunch, and I learned a lot from them. I'm just doing something different. I hope to meet some of them this year and maybe talk shop over drinks at one of the conventions.

    But that said, thanks for the feedback. I'll bear your comments in mind as I move ahead, and make sure to elaborate on the differences in future documentation.

    Cheers,
    --
    N.
  30. The goal of this article is stated as:

    <snip>
    First, it attempts to provide an accurate description of the problems brought about by MVC in servlet middleware.
    </snip>

    I don't feel that the author has succeeded here. He *assumes* that the Struts team didn't implement a certain feature because it would have involved re-writing too much and adding too much complexity. But does this mean that MVC/Servlet frameworks in general are bad? I know of some issues with Struts that really relate more to establishing best practice than anything else. What are the specific issues?

    Incidentally, I think that Holub's Presentation/Abstraction/Control concept is an interesting one, although I still struggle with being able to present multiple views to disparate clients (browser, thick, etc.). But I think there are other ways of handling that.

    Thanks,

    Paul Carter
  31. Specific issues[ Go to top ]

    I'm sorry you feel that way. I'm trying to take a positive approach here, so I refrained from nitpicking every single flaw I've found over the years in the different frameworks. That's both because I respect the guys who wrote them and because there's a larger (anti)pattern at work here and I detailed my specific issues with it. Besides, code speaks louder than words ;)

    Also, I didn't need to assume anything in that example. Everything was written in black and white in an email response to the user. I just reported *one* instance of this type of scenario from *one* project. Trouble is, it happens all the time, in lots of different projects. It doesn't make us bad people, just means our work isn't as cool as it could be. And that's good news, because it means there's a lot of work to do ;)

    Also, incidental to your incidental comment, the Presentation-Abstraction-Control (PAC) pattern has been around for a good sixteen years at least. J. Coutaz wrote "PAC, an Object Oriented Model for Dialog Design". for Proceedings Interact in 1987, and I'm not even sure that's where it originated.

    You should check out "citeseer"--you can find it on google. There are a *ton* of great research papers there that we can turn to when we're working on this stuff. I have a great time there, and learn quite a lot. MVC/PAC, UI, Role-modeling, AOP, framework architecture strategies all that's been around since the 80s (at least), and the place is a research paper goldmine for middleware developers.

    Also, I totally agree about the presentation tier being its own problem space, still unsolved. That's for another article and another project, though ;)

    Cheers,
    --
    N. Alex Rupp
  32. I'll preface this by saying I haven't read the article yet and just looked at the front page of the Shocks site...

    I start to get worried when a framework does too much. For instance, adding workflow and data access to a web framework seems... unclean to me. I don't want to be limited by what you think workflow should be or how you want me to access data (not necessarily in this case, just in general). I want small loosely coupled tools which I can put together to do exactly what I want.

    XWork is a good example of this (yes, I'm one of the main developers), since it, at it's heart, is just a command pattern implementation with nice things like type conversion, interceptors, and our value stack to allow for dynamic property access.

    WebWork2 is really just the web adapter for XWork.

    You could easily plug in workflow and continuations as an Interceptor. In fact, one of the session token interceptors (which keep you from posting a form twice) actually save the entire processing state to the session and re-render for subsequent form posts without having to re-execute. It's not that difficult when your tools are small, have well defined interfaces, and are easily extended.
  33. Jason, I agree with you, and I would really like it if you read the article before making up your mind. Commenting at this point seems premature.

    I specifically am trying to avoid doing "too much" with this, which is why I've abstracted out the development platform from the workflow core. I want it to do a few things really well and allow the things *you* do really well to be plugged into it. Webwork has some core functionality and really cool features which I don't even want to touch at this point.

    And because I'm always skeptical about my work, I've left the door wide open for the workflow system to change down the line. I designed it to be very interface heavy (almost every class in the system implements one of a handful of very basic interfaces) and extremely modular. As it stands, the entire workflow system is a core module which could easily be replaced. I'm seriously looking into Werkflow and Drools, and considering swapping out my core workflow system with a better, more well developed business rules engine like one of those, and then writing tools to simplify the configuration process during development.

    The things you were talking about--value stacks, type conversions, interceptors--are all easily plugged into shocks at runtime. Small tools, well defined interfaces and easy extensibility are all a part of that.

    Anyway, feel free to drop me an email and we'll chat about it some more after you've read the article (and hopefully part two ;)

    Cheers,
    --
    N. Alex Rupp
  34. Why MVC isn't really MVC[ Go to top ]

    I agree there is an MVC anti-pattern but it isn't really MVC. A Servlet is used as a Controller but it's really an all purpose Request – Response handler. JSP is used as a View, it compiles to a Servlet so it too is an all purpose Request – Response handler.

    The gist of Rod Johnson's reasons for deriving Spring's MVC framework from Struts is that Struts should have been strictly a Controller but is instead entangled with its own model objects producing a separate set of objects that overlap the domain. The presentation layer should use Action and Workflow objects in the domain layer. If the presentation layer has separate Action, Workflow, Validation, Value Object, you get 2 overlapping models creating the mess we've become accustomed to.

    Servlets as Controllers typically entangle HTTP requests with request processing logic, when you need to process requests in a SOAP or JMS message you have to refactor or write redundant request processing code.

    Separating Model View Controller concerns is a good thing. The anti-pattern is entangling the concerns and calling it MVC.

    Gary
  35. Why MVC isn't really MVC[ Go to top ]

    The gist of Rod Johnson's reasons for deriving Spring's MVC framework from Struts is that Struts should have been strictly a Controller but is instead entangled with its own model objects producing a separate set of objects that overlap the domain.
    Actually the Spring MVC framework doesn't descend from Struts, but from a framework I wrote in early 2000 (before Struts appeared), which is still in production on a high-profile web site. But I agree that it's pretty similar as a model, except arguably cleaner and a lot more extensible, and that I/we borrowed some good ideas from Struts as well, such as actions that contain multiple handler method.

    I haven't read Alex's article in detail yet, but look forward to when I'm less caught up in coding and writing. I think it's great to have fresh thinking on this issue.

    Regards,
    Rod
  36. Finally some sense.[ Go to top ]

    Web is not ment for MVC. It adds more problems than it solves.

    How many of you implementing MVC, have disabled the browser back buttons, removed the address bar. MVC forces you to take normal browser control away from the user, because state on the server can go out-of-sync.

    Things like adding link become adding an event. e.g. link to product, previously I could have written a custom tag, that wrtie the URL with product number as parameter. Now, with MVC it becomes a "Event", that must be handled by the action, EVERY action!!! So, now, every page that has link to product view, now needs to know how to handle the event, AAAAAAAAAHHH. Instead of just creating a link and forgeting about it.

    WEB is more than fat UI. Trying to implement swing ideas on web, just creates more headache.
  37. hi,

    very interested to read you article, but disappointed:
    I would like to know, black on white, with some hard facts to backup your arguments, why Struts is not enough.

    but you seem to avoid this, or I just did not find it in your article

    I agree there are some things to argue against Struts-MVC, but I would like to see some examples from you, especially the points where you new alternative solution differs from Struts

    and you confuse me by saying this:

    <quote>
    The point is that no matter how you cut it, ...<snip>... no matter how many books you write on the topic, nobody has ever been able to adequately explain how an n-tiered servlet component infrastructure is supposed to implement the Model-View-Controller pattern.
    </quote>

    and this

    <quote>
    A good friend of mine swears he went to a presentation by Craig McLanahan where he brought up a diagram of MVC and there were four boxes. Model, View, Control and ... ? There have been so many half-hearted explanations about how "actions are really Controller components and ..." ad nauseum. I'm sure you've heard it all a hundred thousand times.
    </quote>

    your good friend could not explain you ?
    maybe box #4 was around the three others and was labeled 'Struts' :-)

    Do you criticize MVC and its Struts implementation or MVC on an n-tiered J2ee application ?

    to me the MVC is on the web-tier only (Struts) and not on all the tiers at once

    could you point me to some answers on this, or explain it on this thread ?

    thanks in advance
    Wouter.
  38. Wouter,

    These are really good questions. Fortunately, I don't have to answer them--you can find your answers in the current Struts source download. There's a file in jakarta-struts-1.1-src\doc\proposals from this June called "workflow.xml" that roughly describes what I've just implemented in Shocks.

    In this file, Craig McClanahan outlines his thoughts on the weaknesses of Struts and describes a "workflow management system" to address them. He breaks down the system into a collection of different roles which are nearly identical to what I've built in Shocks. I used some different terms, but I think a lot of our ideas and goals are analogous.

    Too bad Craig and I never spoke at JavaOne :( I didn't know about this document until tonight, but it's heartening to know I'm on the right track. I haven't returned to the Struts code since last spring. I might have to talk with Mr. McClanahan about his ideas and see if we can strike up some collaboration.

    Have fun reading this. I hope it helps ;)
    --
    N. Alex Rupp
  39. great, I was not aware of this document

    this mainly is what I am looking for

    thanks for the quick feedback!

    Wouter.
  40. Not a bad article as a reminder, but I believe it is not quite to the point in analyzing the problem.

    As you point out in the article, there are Patterns and AntiPatterns. Basically, a Pattern may be an AntiPattern at the same time if used in the wrong context or for solving the wrong problem.

    I agree the MVC-Pattern as currently used does not solve all the problems that it may have originally been designed for. In fact, from reading the original problem-statement in your article (without reading all the cited follow-ups etc) I can not make a straightforward link to the current interpretation of the pattern...

    On the other hand, you seem to argue that MVC does not fit with n-Tier Architecture (I think it is fair to say that the problem is not so much servlets but rather thin-client and thus 3+ tiers) and that we need a completely new pattern.

    I disagree. The problem with MVC in a multi-tier environment to me seems to be that you should not (and probably can not) separate the M, the V and the C over the tiers, but that on the other hand you should not model all M'ing, V'ing anc C'ing on the presentation layer.

    To give an example that should prove the point: We use Struts in a large project (3-Tier) and frequently have confusion about responsibilities for the following reason:

    - We believe business rules should be enforced (and defined) in middle-tier
    - However, we do not want to go back to middle-tier more often than necessary

    We have separated syntactic validation to take place on front-end (i.e. in the Struts-layer, not in the jsp's!) and try to leave the rest to middle-tier. On the front-end, according to current believes we unarguably have MVC (by using Struts). On the middle-tier, people would usually not expect to see MVC again - and in fact we do not explicitely have it there.

    There are (at least) 2 problems with the approach:
    1) Consider WebService-Clients. Here, due to the fact that some validation is done in our Struts-layer, we need custom code (or rely on the WebService-Consumer, which is not a good idea). However, some variant of MVC should fit our needs for this case.
    2) From time to time what seemed to be syntactic validation only becomes either context-dependent (which to me makes it too complex to leave it to the Struts-layer) or real 'business-rule driven' (which rules it out as Struts-layer responsiblity). Again, in order to make the middle-tier part of the (typical MVC-task of doing) validation as explicit and understandable as possible, some variant of MVC should be useful on middle-tier.

    So my current view is that MVC presents a valid and worthwhile separational (of concerns) pattern, but you need it in the presentation-layer (for obvious reasons) as well as on middle-tier (sic!). Quite obviously, the 'view'-component of the middle-tier MVC is badly named, but it still is worthwhile as for the same domain-object (model) you may want different (in this case:) technical representations (views) depending on the client-type and context.

    An obvious problem is that you need a clear-cut rule as to what is done on the different tiers. I currently have no general answer.

    I must admit that (as you probably guessed) we currently do not have a clear MVC-architecture on middle-tier. So it is still time to convince me otherwise and any suggestions are very welcome!

    Bottom line: Interpret MVC as 'domain Model component', '(context-specific) View on the domain-model component' and '(control-flow) Controller component' and be bold enough to go for multiple MVCs and the screwdriver turns back into a hammer (still, obviously you shouldn't use a hammer for everything and the knowledge of other architectural patterns is advisable ;-)).

    Cheers, B.

  41. > So my current view is that MVC presents a valid and worthwhile separational (of concerns) pattern, but you need it in the presentation-layer (for obvious reasons) as well as on middle-tier (sic!).
    >
    Pardon me while I rephrase what you're saying in order to make my point. If the presentation layer has its own model you'll have redundant model code in the presentation and domain layer. This is a problem with most MVC frameworks. If you have a remote domain or remote transparency (EJB's) you'll have redundant model and perhaps view code in the presentation and domain layer.

    If the controller directly calls the domain you bypass these redundancies.
  42. Correct, there is the risk of duplicating code. The controllers are the biggest issue, really. However, I think the following is a useful separation:
    - The middle-tier 'view' for a specific client-type will be the client-'model'.
    - The presentation 'view' are e.g. jsp's
    - The middle-tier 'controller' is really the workflow-engine, whereas e.g. a html-front-end controller would be responsible for page-flow and validations where applicable.

    I think you need a domain-'controller' instance and that would have to sit in the business-layer which should not be presentation.

    Cheers, B.
  43. MVC: A New Look[ Go to top ]

    That feature does sound neat in article. I know of other exaples where good code did not make it in.
    HOWEVER... a strength of Struts IS the DEVELOPER COMMUNITY support and interactivty. No other framework comes close to the developer culture relative to this Struts, for example this mail list.

    It's also OK to be simple and not heavy. It does everything you need and does not get in the way when you need to do something it was not designed to do.

    There are a dozen frameworks out there... they all start by saying :"We are better than Struts becuase ... "
    The point is that Struts is the most popular framework out there by far. Like how many books do they have on XYZ framework? How many people ofer training on it? If you get on a project... chances are it's Struts. So knowing Spring or 20 other things out there will not help you. Struts + DAO looks good on a resume. Else you have to explain what it is. 6 developers who all have 6 different things "better" than Struts.

    I look as Struts (using Churchill's words) like this:
    "It is the worst framework.... except for every other one out there".

    I find Struts to be the simplest framework to use, you just have to dispatch in action, and if you need to work on someone else's code, take a peak at Struts.config, and you know where the M,V and C is.

    Struts will not fail you project, it is production proven.


    I think JSF is far behind a lot of other frameworks in features/benefits, and I will document specifics why only a newbie would use JSF, once it ships.

    .V
  44. MVC: A New Look[ Go to top ]

    Vic,

    > The point is that Struts is the most popular framework out there by far. Like how many books do they have on XYZ framework? How many people ofer training on it? If you get on a project... chances are it's Struts. So knowing Spring or 20 other things out there will not help you. Struts + DAO looks good on a resume.

    What you're referring to is "resume-driven development", i.e. choosing the technology that sounds best on your resume rather than the technologically soundest and most appropriate one. I can understand that people act that way, but it's still something to overcome rather than recommend - else, things would never evolve.
     
    > I look as Struts (using Churchill's words) like this:
    > "It is the worst framework.... except for every other one out there".

    I think we need to clarify a couple of things here. You're misleading in your use of the term "framework" here: You leave the impression that a J2EE project can just be built on one single framework. In reality, a number of frameworks that address different concerns can be combined and often work together nicely: Spring and Hibernate is such a popular combo, for example.

    FYI, there are numerous users that choose Struts for the web tier plus Spring for the middle tier, often combined with Hibernate for data access. The rationale is typically to reuse existing Struts knowledge - a valid concern. Other people are using WebWork or WebWork2 on top of a Spring middle tier: WebWork2 even has explicit Spring integration now, developed by Atlassian.

    Note that an important concern that Spring addresses is DAO abstraction, combined with generic transaction management. Many of the "Struts + DAO" applications that you refer to solve this via hard-coded ad-hoc singletons, resulting in a less-than-perfect architecture. Spring's middle tier support is an appropriate addition to such a mix, solving issues that neither Struts nor typcial data access tools address.

    BTW, in the upcoming release 1.0 M4 of the Spring Framework, we will introduce support for the iBATIS Database Layer. We will also ship an adapted version of Clinton's JPetStore, with alternative Struts/Spring web tiers, a Spring-managed middle tier with declarative transaction management, and iBATIS as data access strategy. It uses the very same user interface and data model as the original JPetStore, "just" improving in terms of internal architecture.

    Juergen
    (Spring Framework developer)
  45. MVC: A New Look[ Go to top ]

    Juergen,

    I do not think you understood my message. I was saying Struts is most popular for a reason, and sucess and track record are a good thing, not a bad thing.
    Note that you compre Spring to Struts, as does WebWork and 12 others.

    However, I will look at Spring very closely, once iBatis is a part of it.
    Does Spring work with DisplayTag, Struts Menu, JSTL tag libs?

    Note that many experienced people are properly igonring JSF, IMO mostly newbies are still expecting something from it. It's just like EJB, people use Hibrenate or Ibatis.

    Also, I am planing a large seminar in NYC with name speakers; I would be glad to have somone present Spring to the Struts audience. (also WebWork, maybe one other major)

    .V
  46. MVC: A New Look[ Go to top ]

    I do not think you understood my message. I was saying Struts is most popular for a reason, and sucess and track record are a good thing, not a bad thing.

    > Note that you compre Spring to Struts, as does WebWork and 12 others.

    You're right that there is value in a track record, and I don't intend to discredit Struts in general or your usage of Struts in particular. I just reacted to that "resume" comment of yours :-)
     
    > However, I will look at Spring very closely, once iBatis is a part of it.
    > Does Spring work with DisplayTag, Struts Menu, JSTL tag libs?

    As I said, Spring can serve as middle tier framework for *any* web tier. We have people that use it with Struts, WebWork, WebWork2, and Tapestry. You're free to code your web tier as you like: You simply access Spring-managed business objects from your controllers/actions. So Struts will work as usual, including all tag libraries etc - Spring does not affect this at all.

    Spring's own web MVC is just an option, a feature that you can use but by no means have to. The framework is cleanly layered for maximum reuse: People are using Spring's middle tier support in Swing applications and standalone servers, for example, with the full power of declarative transactions and DAO abstraction. We've even seen usage of Spring's core bean factory in applets!

    Spring 1.0 M4 will be released within about a week. The iBATIS support and our adapted JPetStore version have already been in CVS for quite a while. As I said, our JPetStore offers alternative Struts and Spring web tiers that both access a common Spring-managed middle tier. Have a look at it, it illustrates the separation nicely.

    BTW, I've adapted JPetStore's Struts web tier to Struts 1.1 plus JSTL: The Spring web MVC views use JSTL too, making them as similar as possible.
     
    > Also, I am planing a large seminar in NYC with name speakers; I would be glad to have somone present Spring to the Struts audience. (also WebWork, maybe one other major)

    Do you mean in terms of Spring's web MVC as alternative to Struts? I guess it will be equally if not more interesting to outline the benefits that Spring brings as middle tier framework for Struts, possibly in combination with Hibernate or iBATIS. Our JPetStore version can serve as nice illustration here.

    Thanks for the invitation: I would be glad if someone from the Spring team presented at your seminar! If expenses are paid adequately, we should manage to be there :-)

    Juergen
  47. MVC: A New Look[ Go to top ]

    Spring 1.0 M4 will be released within about a week.


    Also Struts 1.2.0 is schedule for release this weekend AFAIK.
    New commons validator, Tiles-EL, * forwards is main new features.

    .V
  48. MVC: A New Look[ Go to top ]

    Juergen,

    >
    > I do not think you understood my message. I was saying Struts is most popular for a reason, and sucess and track record are a good thing, not a bad thing.
    > Note that you compre Spring to Struts, as does WebWork and 12 others.

    Struts is popular (IMHO) because of 2 things:

    1)timing

    2)At the time Apache Jakarta was new and exciting and we all thought Apache in the Java world would mean quality

    >
    > However, I will look at Spring very closely, once iBatis is a part of it.
    > Does Spring work with DisplayTag, Struts Menu, JSTL tag libs?
    >
    > Note that many experienced people are properly igonring JSF, IMO mostly newbies are still expecting something from it. It's just like EJB, people use Hibrenate or Ibatis.
    >
    > Also, I am planing a large seminar in NYC with name speakers; I would be glad to have somone present Spring to the Struts audience. (also WebWork, maybe one other major)
    >
    > .V


    Let me know if you want someone there for WebWork2. I'm in Rochester, so it's a quick flight over to NYC.

    Jason
  49. MVC: A New Look[ Go to top ]


    > Let me know if you want someone there for WebWork2. I'm in Rochester, so it's a quick flight over to NYC.
    >
    > Jason

    Cool!

    My e-mail is cekvenich_vic at baseBeans.com.
    Send me your e-mail-s, it will be fun.

    .V
  50. Apache's quality, MVC: A New Look[ Go to top ]

    ...we all thought Apache in the Java world would mean quality.

    Xindice dispelled that illusion for me.
  51. Resume padding, MVC: A New Look[ Go to top ]

    What you're referring to is "resume-driven development", i.e. choosing the technology that sounds best on your resume rather than the technologically soundest and most appropriate one.

    Without such a common motivation, there might not be the critical mass needed for TheServerSide to survive. I wonder if resume padding serves higher purposes (eg, technology diffusion and upward labor mobility) in the software market. Does market competition punish a firm staffed by engineers bent on accumulating hot skills? As a career-long individual contributor, I've never had the architectural authority to select technology, so sadly resume padding has never been an option for me.
  52. Resume padding, MVC: A New Look[ Go to top ]

    What you're referring to is "resume-driven development", i.e. choosing the technology that sounds best on your resume rather than the technologically soundest and most appropriate one.

    >
    > Without such a common motivation, there might not be the critical mass needed for TheServerSide to survive. I wonder if resume padding serves higher purposes (eg, technology diffusion and upward labor mobility) in the software market. Does market competition punish a firm staffed by engineers bent on accumulating hot skills? As a career-long individual contributor, I've never had the architectural authority to select technology, so sadly resume padding has never been an option for me.


    Yes, resume padding has many consequences. For instance, EJBs were big for the resume, so everyone used them in wildly inappropriate ways. This caused the cost of building J2EE applications to be vastly higher than necessary. Is it a coincidence that we now see offshore outsourcing becoming so popular?

    We need to learn to do the right thing for our business needs, which often means simpler architectures. It may not look as sexy, but does your intranet timesheet application really need a n-tiered distributed architecture or a massive message bus? I don't think so.
  53. If japanese know english they will put case because VB.net or asp is converted in a new form by Japanese Industrial 5S technology

    pls le2rn Japanese 5s is very simple powerful

    by Sreedhar cusreedhar at yahoo dot com 91-44-23613593