Re: MVC abuse

Question

It's possible we're talking about two separate things. However, the Model-Controller-View paradigm specifically allows for the maximum amount of flexibility. Model in this case generally means the data model, or the data source.
For example, let's take a typical eBusiness portal-slash-web site. Normally you have a series of web pages (the HTML output, and the forms) representing the view aspects, some sort of business logic (the Servlets and other class files) representing the controller, and the database itself as the model. Say, a human resources application that determines your available sick days and vacation days.
If the system was designed according to MVC principles, then you should be able to swap any one of these three components without affecting the other two. Let's say in theory that two years down the road, your boss decides they can't afford to pay the Microsoft Tax, and rather than conducting business through a web browser, he wants to switch to a desktop Java application. You should then be able to code a swing component (view) that calls the existing business logic (controller) and database access (model) code. Similarly, if you decide to change the database from say Sybase to Oracle, then all you need to do is change the database access (model) aspect.
In your example, the advantage of a MVC architecture would be that all you need to do is change the business logic in order to add new operations. Or alternatively, if you changed the model, the controller and the view should effortlessly recognize the changes in the model without any intervention on your part. Realistically, especially when it comes to web pages, at least two if not all three components probably need to be changed, which is why most people don't bother following the philosophy closely.
I do stress it's possible we're talking about two different MVCs; we do have different definitions of "model" for example. But in theory, if your application was MVC-compliant, then you should never have any maintenance pains - it's so well designed and modular that changes made to one component don't break the others.

Answer 1

I hope I have not annoyed everybody yet.
I would like to try to explain myself one more time as I still have not figured out the answer for myself.
For the sake of argument lets separate Model component in two layers and call them Logic and Flow.
Logic consists of pure business logic methods/information and includes cached, SQL statements, calculating the result (in whatever type), etc.
Flow ties multiple Logic pieces together into one invocation block.
Lets say form validation is a separate notion. Broken down this way the Model component would look as follows (l: means logic, f: means flow)
l: process session, load information
f: if OK invoke registration logic. Get username from 3rd party token, business ID from session manager and password from user form
l: create account
f: if not OK return to form JSP, if OK set up purchasing parameters (price, etc.) and proceed to purchasing; to identify payment attributes use payment reference table from MySQL DB, business ID from session management, date of birth, etc.
l: add purchase record to the database together
f: if not OK forward to error JSP, otherwise update account tokens
In the above example, Logic components do not change almost ever. However Flow can depend on systems involved in the particular task and has to be flexible if the directives do not form just one-two complete Model elements.
So, Logic elements can (and have to) be compiled Java classes deployable as JAR units. Flow elements have to be lights weight scriptable as we do not want to have a separate Action class for every marketing request and we do not want to break the flow into multiple HTTP requests where it is not needed.
Either because I do not understand these systems yet good enough or for whatever other reason I do not see any reasonably easy way to implement such business logic flexibility in Struts or in JavaServer Faces.
PS Please forgive a little clumsy example. I did not have time for more sophisticated one but I do have similar real life examples.
PPS I in no way imply that MVC is a bad concept. I am just trying to figure out whether it applies for a certain class of problems (flexible and restructurable business requiements)