MVC or event-driven component-oriented web frameworks? [closed]

Answer 1

The technology used is usually not matter of choice and especially in a big company you don't have many options.

If I were able to choose a technology, in Java I would pick Wicket. I have been using Spring MVC and it is good, but Wicket has a neat features that Spring MVC has not: server-side state management and encapsulation, rich component model, no unnecessary XML mapping files - just pure Java and HTML.

Answer 2

Personally I would say MVC is the way to go for web sites. You have a lot more control over the HTML and CSS and at the same time the controller pattern works very well with HTTP. Event driven web programming is great for small sites or for people who are not that clued up with HTML and CSS and more low-level concepts.

Answer 3

Right now, the 'new hotness' trend is towards the MVC approach. I personally prefer the conventions of MVC frameworks, as a lot of the scut work that takes up valuable development time is done away with. That being said, the constraints tend to be fairly rigid, and a more traditional component-based approach might be needed in certain situations. All in all, it's a right tool for the job sort of choice.

Answer 4

I'm a php dev by day; however, I strongly prefer Wicket and/or Lift, especially the latter. The problem with Prado seems to be that the controller is tied to the page, rather than the logical controls on the page, otherwise, it still seems better than most other options in PHP land. I think all boils down to reusability, unless you have components that are backed by controllers, you can't separate the display all that well from the backing control logic.

MVC as implmented by all these 'MVC' frameworks seems to suck, you get a logical page with a tonne of controls and you have to handle all those on page controllers, wow, thanks, now I have MVC / n, where n is the number of controls. Most 'MVC' systems that I've seen so far, have been a mish-mash of brain-dead tag libraries, contorting request response into a single controller that has to be aware of everything on the page.

xhtml templates with js, and css wonderfully separated. Along with a few classes backing those components, and all of a sudden you're not busy wondering how complex pages are going to work, or if you want to take piece x, and drop it somewhere else.

Answer 5

I loosely follow these guidelines:

• Web Forms/SQLDataSource- Quick and dirty app for internal use to show reporting or some other such data.
• MVC- Simple to complex business logic for a core product.
• MVC/REST Web Services/jQuery- HTML/Whatever type of client RIA's (when user experience reigns supreme).
• Flash/Flex RIA- Useful when an extremely rich client is needed (think multimedia manipulation here).

There are a lot of gaps in this list of course but that just represents how complicated a question it is.

Answer 6

I'm primarily an ASP.Net developer, but I find MVC is a better way of creating functionally complex websites (typically Line-of-Business type sites) since it allows for better separation of business logic and rules from the markup used to display data to the end-user. For quick and dirty sites (typically with a direct connection to the database) or richer interfaces, the "event-driven component-oriented" model is more effective.