Should i use a Model 1 Architecture in this case?

Discussions

Web tier: servlets, JSP, Web frameworks: Should i use a Model 1 Architecture in this case?

  1. Should i use a Model 1 Architecture in this case? (3 messages)

    Hi,
    i've just started a new piece of work for a client which is a little different to what i normally do, and i'm a little sure how to go about it.
    The client site i have been asked to build is basically brochure-ware. It is not very large (at most 100 pages), and currently there is no database access required.
    I am not keen on using a model 1 architecture as at some point in the future the site may come to have additional and more sophisticated functionality, yet at the same time using an mvc framework like struts or spring seems a bit over the top for a website like this.
    Does anyone have any views on this? Do people use mvc frameworks for websites where there is essentially no model???
    Basically all i'd be doing would be using the controller to intercept page requests and forward from one .jsp to another. Is an mvc framework overkill for this? Should i just use a model 1 architecture and run the risk of creating code which may be hard to extend further down the line?
    Many thanks in advance
    P
  2. I guess you need to check that with your client, if they anticipate more sophisticated usage in the future. I would strictly go by the requirements and not anticipate anything unless it is part of the requirements document.

    However, even if it might turn out in the future that some pages need database access you still could mix the static pages with dynamic MVC pages.

    If the whole thing is brochure like, why not use a site builder tool and the get the whole thing as fast as possible done? Isn't that what the customers usually wants, the fastest and most cost effective solution?
  3. Within reason, it's best to design for the possibility of change. I would take another look at Spring WebMVC. It's really quite amazingly lightweight and out-of-the-way, particularly compared to Struts.

    For example, you could use a single controller that uses a naming convention to find the view. That way you can keep things simple, without getting a deluge of controllers.

    Once the simple approach succeeds, it's likely somebody will want something a bit more sophisticated, at which point you'll be glad you don't have to explain why doing so requires a complete redesign.

    Plus Spring is just so cool, I can't imagine doing something complicated without it ever again.
  4. thanks for your help
    i did in the end decide to use Spring, and so far i've been really impressed. Having used Struts in the past it's a revelation, and the support for Hibernate looks really cool too.
    I especially like the use of IOC components. I worked with ATG Dynamo for a long time, and although it had many faults, and was anything but lightweight, the Dynamo nucleus was a great way to build reusable (within Dynamo) components. This feature of Spring reminded me alot of that.