Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

MVC/Struts Question

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello. I am the head web developer at a small company that has 3 web applications from very-small to small-but-growing-fast. Currently it's just a loosely coupled collection of servlets running on Jboss/Tomcat. Seeing problems down the road, I have suggested we move to an MVC architecture, more specifically that we move to Struts. This will involve a rewrite of the entire system though, and my boss wants to know why it will be worth it to spend hundreds of thousands of dollars in programmer time to overhaul this system.
In looking at the pro's and cons of MVC and struts, everyone keeps talking about how separation of logic and content is such a great thing, and you're an idiot if you don't understand that. That's lovely and great. I know deep down in my soul that MVC and logic/content separation is good, but "deep-down-in-my-soul" does exactly look good for a cost/benefit analysis. Can anyone give a good, quantifiable explination on why MVC is a good practice and how it will save money in the long run?
- Matt Case :roll:
 
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your question is a bit open ended, so I can't really offer any concrete suggestions, but here's a few comments anyway:
Separation of content and presentation is good because they usually have different "rates of change" - Most applications need look-n-feel changes at quite different times from changes to the internal structure of the data. If you couple the two too closely together, you end up needing to change both aspects every time, which can give you twice the cost for each change, and twice the chance of introducing a bug.
Separation of presentation and content is good because they often require different skills to do well. A good web-designer is more artist than programmer; a good back-end developer is more programmer than artist. Very few people are honestly good at both. Naturally we all want to use the best people for each job, and splitting the responsibilities means more chance that this can happen.
Separation of presentation snd content is good because they require completely different sorts of testing. Testing backgound processing and content is easy to automate and perform at "build time". If you adopt a good proactive unit-testing philosophy you should be able to get close to no "bugs" in your content-generation and processing code. Testing look-n-feel is much harder. Not only does it usualy require the application to already have been built and deployed before testing can start, but many of the requirements are "soft" (it must look neat, for example). These sort of issues are much harder, slower and more expensive to test, and more likely to require last-minute tinkering.
However; separation of presentation and content does not automatically mean using JSP, Struts or any specific technology, however well-hyped.
The trick is to choose a technology or design approach which suits the skills of your team and the real needs of your application. Personally, I feel that JSP and Struts are not as universally applicable as the adherents claim. Alternatives include templating, XML/XSLT styling, specifying look-n-feel components in a database and so on.
I mention a few of these points in more detail in my recent Java Ranch Newsletter article.
If you would like more detailed advice, please tell us a bit more about how you currently generate the HTML for your web interface, and the kind of things you usualy need to change when you add something new to your application.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good suggestions.
I would also advice against a complete rewrite (or even a partial one). The problem with this is that you spend much time and money without producing business value, on the hope that it will pay back later (which isn't much more than speculation, to be honest). Also, you don't have anything usable when you have to stop midway (because funds are spent), and probably need to maintain or even extend the existing application concurrently.
Most probably a better approach will be to refactor the existing application step by step in the direction of a MVC architecture. That is, every time you need to touch the code anyway, you additionally invest some time to transform the architecture into a more pleasant form.
That way, you don't stop generating business value, always have a running system and improve the architecture at the same time.
How does that sound?
 
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the key is reduce complexity, reuse code, and recycle process. MVC / Struts insist us to do that.
[ March 21, 2003: Message edited by: Zulfikar Dharmawan ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Zulfikar Dharmawan:
I think the key is reduce complexity, reuse code, and recycle process. MVC / Struts insist us to do that.


OTOH, neiher MVC nor Struts are the only ways to do that - and depending on circumstances possibly also not the best.
 
Marshal
Posts: 15885
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with Ilja: don't rewrite the web app. The next time you need to add functionality to your web app, you might want to consider just starting with entirely new code built on Struts. Then, if you are happy with the new stuff, you can slowly move the old functionality into it. Bear in mind that "moving" shouldn't be a simple cut-and-paste of code but a rigorous refactoring.
Another thing that might help would be a set of test cases. If you can prove that the new version of the app provides the same functionality as the old version, with the added value of having a good design that is easy to understand, extend, and maintain, then I'm sure you can justify the time and effort spent refactoring.
    Bookmark Topic Watch Topic
  • New Topic