The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

"component model" vs "MVC structure"?

I have been reading about the Java Frameworks for past 2 days, since I asked a question (on joel forum) about which framework is better. There have been many discussions on this forum (which I read after asking my original question). Also read many blog posts / articles. I am not asking in this post that which framework is better. Based on my readings, both Struts2 and Wicket are top level Apache projects, so they must have something good to be on the top level Apache project. As I understand, one uses "component model" and the other uses "MVC structure".

So, what's the difference between "component model" vs "MVC structure"? (This is not a question on which one is better)
New To Java World
Saturday, July 14, 2007
 
 
"Component Model" is like this:

* the HTML, CSS and JavaScript are used on a per-component basis;
* HTML, CSS and JavaScript might be generated at runtime to provide the functionality of the component;
* multiple copies of the component might exist even in the same page, with little code change and redundancy;
* it follows somewhat the way desktop GUI used to behave, for comparison;
* even the "page" might be a component as well, which can contain other components which provide the content of the page most of the time;
* the mapping of the page components to the URLs occurs by configuration or convention with the name of the page component, as components might have unique names to differentiate one from the other of similar type;
* HTML, CSS and JavaScript may be tightly coupled to the given component;
* components behave in an OO way as well, so one component could extend another one and provide some extra functionality which is demanded in a given case;
* components can have their data mapped automatically as per their design and use, as the framework should support data mapping thanks to the knowledge of the components;
* reuse of components in different pages is quite straightforward;
* with components, sometimes it's possible to avoid custom use of the URL for configuration of the application, even though this goes against standards practice;
* depending on the framework, the components could access stateful data on the server on each user interaction, even though this is against the standards practice; the other way is to find a way for the state to be temporarily stored on the user's browser and with it fake a stateful processing or something;

And so on...

"MVC structure" works a little different to that:

* follows more of the "standards practice";
* HTML, CSS and JavaScript are created in a custom way per page and per application;
* for example, you could have one CSS file for the entire application;
* HTML is kept into separated files, generally on a per-page basis;
* frequently, the HTML is not all generated, even though it can be partially generated with some kind of template engine;
* the URL is sacred and is part of your application and you like to use it;
* JavaScript is used scarcely;
* reuse occurs by snippets of pages, which are built just like any page;
* the filename of the page may be used automatically to map the URL;
* the mapping of data is a manual process;
* generally no stateful processing, except when the data is stored in the database or in cookies;

And so on...
Joao Pedrosa
Saturday, July 14, 2007
 
 
Thanks a ton.
New To Java World
Saturday, July 14, 2007
 
 
MVC and component architectural patterns are not mutually exclusive: you can architect a MVC system using components.
Dino Send private email
Monday, July 16, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz