Down to which level does the use of MVC models make sense?

[lukasbuenger]

I'm just getting started with the pureMVC-framework and the mvc principle in general. I discovered this website and it's content. I got into several wikipedia-articles treating the topic last night and now I feel like the mvc model seems to be just the thing I've been looking for to organize my workflow.

Now I have a simple beginner's question:
Down to which level does the use of mvc models make sense?
An example:
I got a form with controllers controlling the data flow between the form mediator and a given proxy, a mediator which provides the form's view with the needed data etc. The form view itself consists of common form elements like radios, checkboxes, dropdowns and so on. Is it sensible to write these lowest level components with mvc principles? Have I misunderstood something?

[puremvc]

The appropriate granularity of the view is one of those balances that you alone must strike in each app.

On the one hand high granularity ( a mediator for each form control) gives maximum separation of view tier concerns, but leads to an explosion of classes, and thus greater complexity.

Minimal granularity (one mediator for the entire view tier) can result in a bloated class that has much more responsibility than it should.

Finding the right balance isn't hard, though. As a rule of thumb, go with fewer mediators to begin with. When you find that a mediator is handling more than 5 or 6 events and notifications for various children its view component, consider whether it makes sense to refactor it into 2 mediators. This also goes for the view components themselves.

Look for instance at the Flex EmployeeAdmin demo.

It has three interrelated panels for selecting and editing employee data.

Now to begin with, just getting it working, those panels and their contents were all in the main MXML application. But then, I refactored each panel into a separate component, simplifying the main app code quite a bit. Once this was done, I created mediators for each custom component.

Have a look at each of those components and their mediators and you'll see a reasonable granularity for that app.

Now later, say one of those panels gets a lot of new functionality. Let's say, depending on the roles selected for the employee, the details panel gets a separate form as a tab in a tab navigator for collecting details about that employee's info for that role.

So now the details panel is much more involved. Its mediator will become overworked in a hurry.

Probably I will register a mediator for each of those forms as they are instantiated.

Now we've moved beyond just granularity but into dynamic registration. And removal of mediators, and the deferred instantiation issues presented by Flex Navigators. See the Slacker demo for how to handle this. But the real point is find the most reasonable granularity you can and as changes come always be evaluating whether you need to divide an actor's responsibilies to make its role clearer and its code simpler. More classes make it easier for teams to work on an app without stepping on each other's toes, but it also make it harder to understand, and can affect performance.
 
-=Cliff>

[lukasbuenger]

Hi Cliff,

thanks for your quick answer. I'll give this some thought.

Lukas