How exactly to use the MVC design pattern

Question

I have read the documentation on the apple's developer website which refer following guidelines

• A view class shouldn't depend on a model class (although this may be unavoidable with some custom views).
• A view class shouldn't have to depend on a mediating controller class.
• A model class shouldn't depend on anything other than other model classes.
• A mediating controller class shouldn’t depend on a model class (although, like views, this may be necessary if it's a custom controller class).
• A mediating controller class shouldn't depend on view classes or on coordinating controller classes.
• A coordinating controller class depends on classes of all MVC role types.

Consider this scenario:

I have a view controller class called EmployeeViewController. I have some minor components of which are some are programmatically created and some are created through xib.

What exactly I am doing is creating all the subviews inside the EmployeeViewController class and adding them to the EmployeeViewController's view, e.g. [self.view addSubView:…]

Is it a better option for me to create a seperate UIView Subclass which consists of all the components and initialize it once and add it in the EmployeeViewController?

What exactly is the correct way to implement MVC? Am I supposed to create separate components for view and controller or should I stack subviews inside the EmployeeViewController?

Answer 1

The basic concept of MVC is to decouple the components (i.e. the model, view and controller).

The advantages of this approach are: less dependencies between the components; more flexibility; and when the design of your application changes, you only need to change the code in one location, not multiple.

For example, in Struts, all the configuration will be written in struts.xml and mapping will be done in such a way that for every action there will be a result (JSP defined).

If you want to change the design or flow, you only have to change struts.xml.

Answer 2

The question you ask is not so much about how to use MVC in general, but how to manage/implement the specific composite views you need.

So having the basics and purpose of MVC design pattern in place, the answer might take multiple paths:

A. use a dependency injection pattern in the main view ie. EmployeeViewController's view to add/inject any sub-views it might need

B. depending on the which view/class is responsible for the data/model the main view itself can generate the sub-views and initialize them

C. not use sub-views at all but re-structure the main view to handle the data by itself in one view

Answer 3

So to me MVC is all about project structure, and here's how I break down MVC.

M for Model: This is everything that has to do with data. From your Core Data, to your network calls, to objects that reformat or translate data to get it ready for the app. Basically where all the cool logic goes.

V for View: This area if for stuff that directly interacts with the user such as storyboards and xibs. That's pretty much it.

C for Controller: This code is code that accepts data from the Model layer (with the data readily formatted), and then transforms it into something that can be presented in the View layer. Basically this is all of your ViewControllers.

The key thing about this approach is that your Model layer should be able to be pulled out and applied to, say, a Mac app with minimal modifications, where as the V & C should be explicitly pertinent to iOS.

That's the way I was taught MVC but I'm sure there are more interpretations.

Now for implementation, it's hard to give you exact advice without sample code but generally, it seems like most of your View stuff is programmatic which you should avoid if you can. Take advantage of storyboards and xibs to take care of static content.

Regarding the UIViews, this isn't so much of an MVC question as it is a software design question. It all depends on the complexity of that view. If it is an extremely intricate and detailed subview, then yes pull it out into it's own class. But if it is just a basic UIView that has a few labels, then just build that in the ViewController. Try to adhere to the Unix philosophy that every class should do only one thing, and do it extremely well. Don't worry if your class only has one function in it. If it is an important and unique function, then it would actually be preferred to have that decoupled out of the Controller layer and into the Model layer. I see too many people afraid to break down their code into simple classes, but that is actually the best way to go, have everything decoupled and thus easily plug-n-play.

So in conclusion, its your call. How complex is this UIView? If it requires a couple of helper functions and global variables, pull it out into a subview.