Sign in to follow this  
DareDeveloper

Model-View-Controller Terminology

Recommended Posts

DareDeveloper    1018
Hi, just covered the MVC pattern in school and now I am a bit confused. When you work with a central dispatcher servlet that forwards the request to a specialist without adding an observer pattern ... is it not real MVC then? Some resources say that the observer pattern is an important part of the MVC pattern. Others say that combining the patterns makes sense but that mvc can also stand on it's own. Is it just that historically (SMALLTALK) is was used that way? And what is more common when JSP and beans are used? Implementing the observer pattern or not?

Share this post


Link to post
Share on other sites
Antheus    2409
MVC is lots of terminology and hype for nothing. It's a popular topic, but simply deals with logic and function separation.

Java APIs use MVC, yet only separate between model, but put view and controller in same bucket.

MVC is a form of 3-tier architecture.
- You have a database that stores data (SQL), which is model.
- Application is the view, the logic, executes querions, and performs the math/processing
- View is your front end, rich UI or web page.

In reality, things aren't that simple. It's not only not always possible to realistically separate view and controller, sometimes all 3 need to intertwine.

But there is no *real* MVC. It simply means that data storage, processing and interface layers exist, or were considered in design.

Part of the problem also comes from the fact, that UI windowing and control logic of today's systems doesn't allow for pure MVC, nor does the web. Or, if you do design pure MVC, it'll be useless in real world, since it'll impose too many restrictions.

Observer pattern in Java is used for all event dispatching. You add a subscriber to an Observable, and then receive event Objects. MVC and Observer are different patterns. One does not exclude the other. In case of Java's libraries, those are mixed liberally, or the libraries would either be useless, or unimplementable.

Model <-observes- View <-observes- Controller is only half of the equation. And observer is only used if the updates are propagated asynchronously.
Model <-polls- View <-polls- Controller is synchronous (SQL is like this, where you don't receive events, but request updates.

But then, you still need a way to send commands from controller towards model. That can again be done through observers or in a different way. It doesn't change the organization of the logic.

Share this post


Link to post
Share on other sites
Quote:
Original post by DareDeveloper
Hi, just covered the MVC pattern in school and now I am a bit confused.
When you work with a central dispatcher servlet that forwards the request to a specialist without adding an observer pattern ... is it not real MVC then?

Some resources say that the observer pattern is an important part of the MVC pattern.
Others say that combining the patterns makes sense but that mvc can also stand on it's own.

Is it just that historically (SMALLTALK) is was used that way?
And what is more common when JSP and beans are used? Implementing the observer pattern or not?


The observer pattern is supposed to make things easier - but it's not a base component of the MVC model, although it's still an important part of it. You can perfectly implemented the model without using any observer, but you have to make sure to get a clear dependency between your objects (i.e. no circular dependency).

Typically, you want the Controler to know the Model and the View, while the View should only know the Model. the Model knows nobody. Of course, this comes at a cost: it is more difficult to have the model changed without user interactions (for example, asynchronous commands might delay the change; to get the changes back, the View has to poll the Model). But for synchronous applications (when the model changes only after user interaction), this is barely OK.

The links are quite different of those you'll get with the canonical MVC model + observers (the View observers the Model, the Model observes the Controller). This setup is superior because it allows you to do synchronous and asynchronous changes to the model.

Now, I can't answer the JSP question - I don't know Java at all (how is that possible? [smile])

Quote:
Original post by Antheus
But there is no *real* MVC. It simply means that data storage, processing and interface layers exist, or were considered in design.

I hope there is, otherwise it would make a good part of my job useless [smile].

BTW, adding some abstraction to your explaination would really help: no need to speak about databases for example. The Model of an application is the complete set of data and processing that are needed to have the application running, regardless of the user input and visual representation.

Quote:
Original post by Antheus
Part of the problem also comes from the fact, that UI windowing and control logic of today's systems doesn't allow for pure MVC, nor does the web. Or, if you do design pure MVC, it'll be useless in real world, since it'll impose too many restrictions.

That's not true: I'm perfectly able to bypass the limitation of the media model to create a real MVC application. I did that several times in the past, and I hope I'll continue (if you don't mind [smile]). I can even say that the applications I design using this architecture are NOT useless.

The model of Windows is what MS implemented in the MFC: the Document/View architecture. The View is responsible for both the user interaction with the application and the representation of the Document (which barely correspond to the MVC's Model). The reason for that is the underlying messaging system which is at the heart of the Windows user interface: it handle both the drawing and the user input in the same way, with the same constraint. But it's easy to overcome this issue and to add an abstraction layer on the top of this management, in order to separate the rendering logic from the user input logic. By doing so, you effectively create an MVC application.

The web itself allows you to create MVC applications as well. I'd say it's even easier, because the server (ie where the model lies) is not able to cope with the user input synchronously - it can only receive requests. Handling these requests can be done by a Controller, which will update the Model, which will in turn trigger the rendering of the View. This is the architecture of most blogging softwares out there.

Best regards,

Share this post


Link to post
Share on other sites
Antheus    2409
Quote:
That's not true: I'm perfectly able to bypass the limitation of the media model to create a real MVC application. I did that several times in the past, and I hope I'll continue (if you don't mind ). I can even say that the applications I design using this architecture are NOT useless.


Unfortunately, I developed an allergy against buzzwords and "rightness" of aproach, with symptoms being nausea and irritability.

As an example: In a project an UI table needed to be made to display 50k floating point values. MVC was obviously used, hyped and pushed down to developers.

So far so good. Unfortunately, framework that provided the MVC abstraction did it completely orthogonally to what was needed. It established a listener on every data value, that was then used to call redraw updates on the table. As such, it completely bypassed the intended MVC Java tables, and caused some annoying side-effects. These were exhibited in application stalling due to creation of 500+ threads during start-up (1 thread for each value), 500Mb heap exhausted in a matter of ms, 30-180 second start-up times and application being completely useless altogether. 18 months later, framework finally offered the solution, and application used it by bypassing both, Java's MVC and framework's MVC, and established its own, single update thread. This final hack took a lot of enteprise grade consulting with plenty of patterns thrown left and right.

Next version of the application used a single table as model, the UI's component for rendering, and a single threaded implementation of a view that handled dirty flags. End result was application running at 50Hz at 0.2% CPU, with startup and memory requirements next to 0.

The equivalent of this would be representing a raster image with each pixel being an object, and an individual instance of listener registered to each pixel, that then calls global repaint. That is perfectly valid MVC, it's considered real, yet horid by its very design.

No, MVC isn't wrong or useless. But I react very negatively when talking about "right" and "wrong" pattern without scope or context. It can be perfectly "correct" MVC - but completely useless.

The only right MVC implementation is the one that completely abstracts the problem at hand. Beyond that, MVC is simply an abstraction of a problem, and the only right way is the one that solves the problem in an optimal way.

Real or unreal MVC for sake of MVC doesn't exist. This is why I gave the database example as just that - an example of MVC applied to common problem of business logic abstraction.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this