The term MVC (Model-View-Controller) gets bandied about on multiple levels. In classic SmallTalk programming, all three roles operate in the same program space to define update/event operations among a Model (the in-memory collection of data), a View (the presentation of data peculiar to the interests of one user), and a Controller (the exposed component that allow a user to request modifications to the model or the view perspective).
The idea behind this pattern is to separate the issues of modelling, viewing and controlling underlying data so that only the agreement between these roles (their public interfaces) remains a constant, leaving their implementation as a detail the systems programmer can vary as needed. The information changes between these roles are often described as updates, or events in Swing/AWT/JavaBeans parlance.
To me the idea of an "MVC Architecture" is just a way to leverage the knowledge of this pattern as a
J2EE development best practice. The term, in my opinion, doesn't have much to do with establishing a helpful, well-documented, resuable pattern of class relationships. I see the primary intent of this term as a means to persuade developers that if they know MVC from a previous context, they can apply that understanding to J2EE development. The reuse is in this case conceptual.
To put more rubber on the road, we see recommendations of Model 1, Model 1-1/2 and Model 2 architectures in Sun's best practices guides, all of which are variations on the MVC Architecture concept.
