Model View Controller (MVC)

Updated on January 27, 2020
Bagexito profile image

Keen interest in finding different solutions to a problem. Currently exploring different architectures for iOS applications.

Problems We Are Dealing With

In almost all user faced applications, we have User Interface, Business Logic, and Data modules. And every application we design, we want it to be easily Scalable, Testable, Maintainable and Reusable.


One of the scalability factors is how much dependency modules have on each other. It is difficult to change the system if the dependency factor between modules is higher.


For unit testing, we need to isolate part of modules in order to simulate different behaviors a system can have (also known as Mocking). When operations are not divided into modules or the modules are tightly coupled than testing becomes very hard.


It shows how much complexity of your program grows with the growth of functionality. If functionality grows to some extreme, managing code base and its testing should remain easy.


This means make a group of operations called Modules and then use that module where needed rather writing the same operations again and again.

Example Problem

To elaborate on different designs, let's consider this example. We are building a Profile Viewer application. It will be a single view (means only one screen) application that fetches your profile from the server and displays info on the screen. Users can also update their profile information from the same screen.

The quality of each method we discuss below will be measured by the design parameters discussed above.

Naive Approach

If you are new to programming and not using some framework, then you might end up with one class ProfileView which have all the followings:

  1. Profile data model.
  2. Network operations to get and save the profile.
  3. View elements e.g. Text, Label, ImageView, etc.

It will look something like this:

class ProfileView : View {

	var profile: ProfileDataModel;
	var nameTxt: TextView;
	var pic: ImageView;

	void loadData()
	void saveData()
	void render()

Lets gage this method with our design parameters:


  • One class (ProfileView) that does all the stuff including UI rendering, loading and saving data, data model, UI updating and network operation.
  • If you want to change anything you have to update ProfileView.
  • Profile view knows exact data and its source which creates tight coupling.


  • Difficult to mock the functionality of ProfileView to perform unit testing.
  • We can test and mock some of the functionalities by subclassing ProfileView, if functionality is divided into proper unit functions.


  • Class will become huge and complex even with medium functionalities.


  • This method does not implement any reusable code as it should be. For example, it can extract network operations into a separate module.

MVC to the Rescue

This design suggests separating god class (described above) into three sections, i.e. Model, View, and Controller. Each section will have the following responsibilities:

  • Model: It will contain the data of the application.
  • View: It will display everything on the screen that allows the user to interact.
  • Controller: It will glue View and Model together. It handles two things: first, it will get data from the Model and fill the UI. Second, it will get inputs from View and update the Model.

There is one exception to MVC, i.e. in apple version of MVC Controller and View are tightly coupled and it's difficult to mock view in order to completely test the controller class.

So now if we apply MVC on our ProfileViewer application it will look as follows:

Let's see how this method improves the previous method:


  • Both View and Model are now lives and works separately in the application.
  • View and Model are not dependent on each other directly.
  • Controller knows from where to get data, how to convert it into displayable form and update UI.
  • Controller is handling and reflecting all UI actions on model.
  • Controller get very big if views are complex.


  • We can test the model and services separately.
  • We can test the controllers and UI by mocking the model.
  • Testing becomes difficult (not impossible) when the controller gets big like lots of view, animations, lists, and actions, etc.
  • Difficult to test different states of UI.


  • As design has divided code in modules, it's easy to maintain different parts.
  • The controller becomes messy when it get bigs like lots of view, animations, lists, and actions, etc.


  • We can replace different views with the same model/services.
  • As we get Model through services like Api Client which will use Network Client to request server. All these modules can be re-used.


In this article we have discussed the followings:

  • Design parameters we are trying to achieve when we build user faced applications.
  • How design parameters affect the quality of the software.
  • What is the naive approach and how it's not a good option.
  • What is MVC and how it improves the design of the software.

There are other design patterns like MVP, MVVM, Viper, etc that also provides a solution to this problem.

I hope this article helped you in understanding the concept of MVC. Kindly do share your comments in the section below.

© 2019 BAG


    0 of 8192 characters used
    Post Comment

    No comments yet.


    This website uses cookies

    As a user in the EEA, your approval is needed on a few things. To provide a better website experience, uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

    For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at:

    Show Details
    HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
    LoginThis is necessary to sign in to the HubPages Service.
    Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
    AkismetThis is used to detect comment spam. (Privacy Policy)
    HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
    HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
    Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
    CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
    Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the or domains, for performance and efficiency reasons. (Privacy Policy)
    Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
    Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
    Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
    Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
    Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
    VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
    PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
    Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
    MavenThis supports the Maven widget and search functionality. (Privacy Policy)
    Google AdSenseThis is an ad network. (Privacy Policy)
    Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
    Index ExchangeThis is an ad network. (Privacy Policy)
    SovrnThis is an ad network. (Privacy Policy)
    Facebook AdsThis is an ad network. (Privacy Policy)
    Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
    AppNexusThis is an ad network. (Privacy Policy)
    OpenxThis is an ad network. (Privacy Policy)
    Rubicon ProjectThis is an ad network. (Privacy Policy)
    TripleLiftThis is an ad network. (Privacy Policy)
    Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
    Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
    Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
    Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
    ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
    Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)
    ClickscoThis is a data management platform studying reader behavior (Privacy Policy)