MVC Design - How many controllers?

Overview

I’m building a simple web application consisting of a canvas and elements on the canvas.

The canvas supports the following operations: load, save

The elements support the following operations: move, resize

JavaScript on the web page sends a message to the server for each operation and the server sends an appropriate response.

My design

Note: the arrow between the Canvas and Element objects is supposed to denote that the Canvas object contains a list of Element objects. I didn't have the right symbols for the diagram.

Example work flow

1. An element on the canvas is moved generating an element_moved message.
2. The front controller manages the session and passes the message to the canvas controller with the correct canvas object.
3. The canvas controller inspects the message and sees that it is for an element on the canvas and passes it on to the element controller.
4. The element controller parses the message and updates the appropriate element object directly.

Question

Is this hierarchical arrangement of controllers common place in MVC designs or am I completely missing the point? I've searched for several hours but haven't found any sites which discuss MVC design in more depth than simply returning a page view.

My motivation behind the design was that each object that the client needs to interact with has a controller so that if the interface changes (to su开发者_JAVA百科pport new methods) then the corresponding controller can be updated without impacting the other parts of the design.

usually you won't have one controller calling another in MVC. What you have specified as Element Controller is really just a part of business logic to update the canvas model. If your use case requires you to update the elements independently of the Canvas, then you will have a separate Element Controller, calling the business logic to update the element.

Cheers, Ryan

Your situation raises fundamental questions when attempting to organize concerns in client-side JavaScript for MVC.

First Fundamental Question

1) Should the entire "page" use one monolithic Controller, where member methods of such a Controller are the event handlers / starting points for working with a single Model and a single View for the entire page?

In regular expression speak ...

Controller{1}

Model{1}

View{1}

Since there is only ever one Controller, there is no ambiguity in the idea that its methods must serve as the event handlers / listeners for input into the scheme: Controller.moveCircle().

Playing dumb for a minute, if there is only ever one Model, then you can simply go to one place to create all the data / state handling methods that you need. Right? (hehehe) ;-) Model.calculatePosition(), Model.calculatePrice()

In the most basic client-side / web scenario, if there is only ever one View, one might think just putting all presentation logic there could get the job done: View.repositionCircle(x, y), View.repositionTriangle(x, y)

Discussion 1

Why might a monolithic Controller, Model, or View scheme like this be problematic in the future?

Can I transfer individual screen elements and their behaviors to other "pages" without any hassle or extra baggage?

Coupling and Cohesion

Think coupling. Does a monolithic Controller loosely or tightly couple accessing screen targets?

Think cohesion. Does a monolithic Controller group behaviors / methods related to accessing an individual target strongly or weakly?

Would Controller.moveCircleUp() and Controller.moveTriangleUp() be dealing with accessing one screen target, or two?

In this case, broad questions like these about a monolithic Controller would also apply to monolithic models and views. A Model is most likely composed of several objects for doing and dealing with the data / state of various things, so there's generally less confusion about it's place.

Yet, if it is a monolith too, then it must deal with the data / state of all screen targets. Even with using multiple object properties and multiple methods in such a model, that could get messy.

Re-usability and Maintainability

What I have written about here cannot be good for code re-usability and maintainability. Even if you are no SOLID expert, it is easy to understand why monoliths tend to violate the Single Responsibility Principle. You should not be in the same place to change something about a circle, where you also make changes for a triangle.

Why? Think of it this way. You are floating in the ocean after your boat capsizes. It is you and another crewman. Would you rather be joined at the hip, so that if he loses consciousness, he or she takes you down too? No, you would want to be independent of the crewman so that you are free to sink or swim on your own.

If you are coupled at the hip, you might hit each other in the face or make some other error that would not have happened if each was a single floater.

In other words, it is better to operate independently and work together, than it is to be joined at the hip and try to accomplish the same things. It is not about when things go well. It is about when thing go wrongly, or when independence is preferable. For example, when one is able to grab a rope ladder dangling from a helicopter, but the other is getting gnawed on by a shark.

You want to be able to reuse application elements in different screens or applications altogether. This is why loose coupling and strong cohesion are fundamental to object-oriented programming, and programming generally.

(**Note: View does not mean HTML only, even if this is the most common end result. Other possibilities include SVG, XML, Canvas graphics, image formats ... anything that fits the circumstance.)

Second Fundamental Question

2) Should each crafted, actionable object / element / target on the screen have its own Controller, Model, and View?

In regular expression speak ...

Controller+ (one or more)

Model+      (one or more)

View+       (one or more)

Discussion 2

Do you want to use screen targets / elements on other pages / screens and bring their specific behaviors with them?

In the first scenario, there is a 1:1:1 relationship between Controller, Model, and View. They are monolithic. There is one screen / webpage. In that setup, you cannot take a circle and put it on another page / screen without bringing along the logic for triangle, too!

If the goal is to make code reusable in another context, then the answer is that each shape requires a self-contained MVC arrangement. Each target would have its own Controller, Model, and View.

In effect, this would mean each screen element that you designate worthy would know how to accept input from an event, process it, and show the output. Some how, we made it back to something that sounds rather fundamental.

Final Thoughts

If one accepts the the above as true, then shapes are, well, alive. :-) They are independent of the context. Manipulating them should not depend on the some all encompassing, JavaScript, FrontController, event handling overlord to be triggered first, only to delegate the work to a method of the target's individual Controller.

PHP MVC

Server-side PHP uses the FrontController scheme before getting to the desired Controller sub-class because if you have a single point of entry into the application (/index.php), you have to translate (route) the HTTP request (/contact/send) into an instance of a Controller, and call the desired method from that controller: ContactController->send().

Performance

The real issue here is how well will the application perform after having downloaded and loaded all of the JavaScript into a user-agent.

Answer? The more you have going on, the more memory you will use. If each screen element has a minimum of three (3) files for its Controller, Model, and View, then ten elements could mean thirty (files to download) at minimum.

Of course, other configurations are possible, but that is where a tool of some sort might come into handy to concatenate and minify everything. In JavaScript, I would rather develop one object per file.

I hope this helps!