There’s no singular way in which a website can be structured. The design patterns of websites vary as much as websites vary themselves. Take a look at Facebook. On its surface, Facebook has to be one of the most complex websites people use on a regular basis. As soon as a user lands on their homepage, the website fires off at least half a dozen requests to fill a page with a multitude of components. Each one of these components are designed to render asynchronously so the failure of one component won’t be consequential to the rest of the page. Now compare that to a website like . One of the greatest draws to Google is the fact that their main website has one of the most famously simple user interfaces on all of the web. But underneath, google.com has to be one the most logically complex web applications anyone can ever think of. Every time a user types a character into its search bar, Google taps into a collection of previously searched phrases to generate autocompleted answers that are estimated to be the most relevant to the user. data Google Now, one can easily imagine that the logic that’s necessary to run an application like Facebook would be very different from the logic that’s necessary to run an application like Google. At its core, any website’s functionality is simply a way in which the front end or the can reach the appropriate to retrieve data. In any case, there will always be a model and there will always be a view. What really changes is the way in which the models and views are connected. view model In the world of web development, there are two main ways in which the view of a website manipulates the model of a website and that’s either with a or with a . And as you’ll see, each method of communication has its own strengths and weaknesses. controller ViewModel MVC: Model-View-Controller Quite possibly the most standard way in which the data model is connected to the view of an application is through an interface called a . In the MVC pattern the controller acts as a tool that directly manipulates the data in its given model. controller A standard authentication controller written in Ruby on Rails. Nowadays, the frontend and backend of websites are set up to be completely decoupled from one and another. User interfaces of websites have become far too complex for the view component of the MVC pattern to be stored within the same file as its data models. The frontend and backend is connected only through get/post requests and JSON strings that are organized through controllers and a router. Router for the same auth controller shown above. This is accomplished within the view by fetch requests that hit specific routes on the API that are tied to controller actions. What a typical login fetch request looks like in React. Each controller is designed to both receive data and send back appropriate information based on the data received. The MVC pattern was specifically designed in such way that the view and the model don’t need to know anything about each other. Because of this, the MVC pattern allows developers to work simultaneously on different components of a web application without impacting one another. However, the MVC design pattern has its many drawbacks. For one, the use of controllers to manipulate data models creates clutter in the backend. It’s standard for each model in a database to have its own controller, so when an application scales much larger and evolves into an operation with many related models, the amount of controllers used must grow in tandem. This coupled with the natural introduction of new layers of abstraction brought on by most frameworks creates a codebase that becomes very difficult to navigate through. At least some of these errors can be taken care of through the use of ViewModels. MVVM: Model-View-ViewModel The popularity of the MVC format can be attributed in no small part to the fact that it’s fairly straight forward to understand in comparison to other design patterns. At face value, the simplest way to connect a disjointed model and view is to create a controller that allows the view to manipulate the data model. However, this indirect approach to allow the view to communicate with the backend isn’t ideal for every application. Specifically, the controller method doesn’t work as well with . single page applications Another popular method to connect the view to the model is through something un-creatively called a . Unlike the controller method, the ViewModel method relies heavily on the frontend of the application. ViewModel AngularJS is a popular framework that prefers the MVVM pattern over MVC. Unlike the MVC method, the ViewModel isn’t a controller. It instead acts as a binder that binds data between the view and model. Whereas the MVC format is specifically designed to create a separation of concerns between the model and view, the MVVM format with data-binding is designed specifically to allow the view and model to communicate directly with each other. This is why single page applications work very well with ViewModels. It’s simple and allows the view to directly communicate with the backend. Because of this, MVVM single page applications can move quickly and fluidly and save information to the database continuously (Google Docs would be a perfect example). However, the MVVM format comes with its own flaws as well. Because it relies on data binding, the ViewModel consumes a considerable amount of memory in comparison to it’s controlling counterparts. The creator of the MVVM pattern himself, John Gossman, said that the overhead for implementing MVVM is “overkill” for simple UI operations (Gossman). Larger applications that use the ViewModel method regularly become incredibly difficult to run. For this reason, the MVVM design pattern is used mostly for single page/function applications on the web. On the Functionality of Websites In these past two decades, we saw the variations of websites increase dramatically. The proliferation of programming languages and the steady increase in computing power over these past years has lead to one’s ability to find any solution to any question or problem imaginable within the click of a mouse. Alongside these innovations came new ways to organize our codebases and new ways in which webpages can connect to the data it needs. There’s no singular way in which a website can be structured. In this blog post, we touched on two. The way in which the aforementioned Facebook is structured is incredibly conducive to the MVC pattern, while the many single page applications created by Google are usually very much more conducive to the MVVM pattern. With this knowledge, I encourage you to go out in the world and view websites differently. The next time you open a webpage in your browser, I like you to think deeply about how it was made. Resources: _In the first part of a series on Angular JS tutorials, the author walks through some design patterns._dzone.com Angular JS Tutorial - MVC and MVVM Design Patterns - DZone Mobile _I've had several questions about when and why to use M-V-VM versus other approaches. The obvious purpose is abstraction…_blogs.msdn.microsoft.com Advantages and disadvantages of M-V-VM _Model-view-controller ( MVC) is a software architectural pattern for implementing user interfaces on computers. It…_en.wikipedia.org Model-view-controller - Wikipedia _MVVM facilitates a separation of development of the graphical user interface - be it via a markup language or GUI code…_en.wikipedia.org Model-view-viewmodel - Wikipedia _After four different designs in the first six months of the development of the upday app, we learned one important…_medium.com Android Architecture Patterns Part 3:Model-View-ViewModel
