MVC, MVP & MVVM - Architectural Patterns.

MVC - Model–View–Controller (MVC) is a software architectural pattern mostly (but not exclusively) for implementing user interfaces on computers. Traditionally used for desktop graphical user interfaces (GUIs), this architecture has become extremely popular for designing web applications.

MVC - Framework Library: Early web MVC frameworks took a thin client approach that placed almost the entire model, view and controller logic on the server. This is still reflected in popular frameworks such as Ruby on Rails, Django, ASP.NET MVC, Spring MVC and Express. Client technologies have matured; frameworks such as AngularJS, EmberJS, JavaScriptMVC, SpineJS and Backbone have been created that allow the MVC components to execute partly on the client.

MVP - Model-View-Presenter (MVP) is a derivation of the model–view–controller (MVC) architectural pattern, and is used mostly for building user interfaces. MVP is a user interface architectural pattern engineered to facilitate automated unit testing and improve the separation of concerns in presentation logic:

• the view is a passive interface that displays data (the model) and routes user commands (events) to the presenter to act upon that data.  
• the model is an interface defining the data to be displayed or otherwise acted upon in the user interface.
• the presenter acts upon the model and the view. It retrieves data from repositories (the model), and formats it for display in the view.

 

MVP - Framework Library: Client Side- Riot.js, GWT   whereas Server Side - Classic ASP.NET, JSP Servlets. In general implementation of MVP: 

• .Net Framework - Claymore, MVC# Framework, Web Client Software Factory, Evolution.Net MVP Framework, ASP.NET Web Forms Model-View-Presenter (MVP), Nucleo.NET, WinForms MVP
•  Java Framework - JavaFX, MVP4J, Echo2, Google Web Toolkit, GWT-Platform, JFace, Swing, Vaadin, ZK
•  PHP Framework - Nette Framework

MVVM - Model–View–ViewModel (MVVM) is a software architectural pattern. MVVM and Presentation Model both derive from the model–view–controller pattern (MVC). MVVM facilitates a separation of development of the graphical user interface (either as markup language or GUI code) from development of the business logic or back-end logic (the data model). Model–view–viewmodel is called model–view–binder, especially in implementations not involving the .NET platform. ZK (a web application framework written in Java) and KnockoutJS (a JavaScript library) use model–view–binder. The MVVM pattern includes three key parts:

1. Model (Business rule, data access, model classes)
2. View (User interface (XAML))
3. ViewModel (Agent or middle man between view and model)

 

MVVM - Framework Library: Client side - Knockout.js, Kendo (MVVM) whereas Server side - WPF (Desk­top) or Sil­verlight, Win­dows Phone apps (XAML), Adobe Flex.  

When to use which?   

• MVC - Use in situations where the connection between the view and the rest of theprogram is not always available (and you can’t effectively employ MVVM or MVP)
• MVP - Use in situations where binding via a datacontext is not possible. 
• MVVM - Use in situations where binding via a datacontext is possible. 

 

Both MVP and MVVM are deriv­a­tives of MVC (see time­lines and how these have evolved). The key dif­fer­ence between them is the depen­dency each layer has on other lay­ers as well as how tightly bound they are to each other. 

Developers concern and take on against Parse (MBaaS) cloud service shut down.

In  this blog we are going to discuss about the challenge and alternate approach of an initiative or best practice adoption after shutting down the Parse service i.e, mobile backend as a service (MBaaS).

As we all know that Facebook has made an announcement about shutting down the Parse cloud service. Currently it's not closed, it will stick around till up to the time of  next year i.e., 28 Jan 2017.

Facebook Parse chief technology officer Kevin Lacker wrote in a blog post,  "We’re proud that we’ve been able to help so many of you build great mobile apps, but we need to focus our resources elsewhere".

Challenge:

After Parse shut down, developer must look elsewhere,

Migration in new environment from existing one,

Dealing and convincing to the existing customers/clients, costing, manpower.. so on

 Growing backend and architecture services team, etc.

Alternative Solution Approach:

 Before we move on towards new alternate adoption it is good to analyze about what features are we looking for ? The list of services are:

• Data Storage
• Push Notifications
• Usage Analytics
• Dashboard
• Social Integration
• User Administration
• Cloud Code Integration
• Multiple Mobile Platform SDKs
• Background Jobs 
• Crash Report

The 'Github Development Community' step ahead of this challenge and a great list of Parse alternatives has already emerged as a result.

In next what developers can do ?

1. Migrate and Host Own Parse Server: Parse has provided a Migration Guide (https://parse.com/docs/server/guide#migrating). Facebook is open-sourcing Parse Server and making available a database migration tool to help move apps off of Parse, that lets you migrate data from Parse app to any MongoDB database. Developers will run most of the Parse API from their own Node.js servers (or one hosted on a platform like Heroku). 
2. Switch to Another SaaS:  Developers need to update their application(s) to leverage new SaaS environment as its backend service, this could also be a great time to upgrade app(s) with improved or added functionality.
3. Build Own Backend Solution: SaaS platforms are great for MVPs, rapid prototyping, personal projects, and powering smaller features of larger products. If your application needs to be built to scale, is mission critical, and continues to evolve with custom needs, it may be a better business strategy to build your own backend. This way you maintain complete control and can leverage it as a competitive advantage.

The difference with Parse is that it has attracted more developers than the existing platforms because of its easy-to-use and well-documented SDKs, highly competitive (often free) pricing, intuitive backend portal, and its ability to handle everything (e.g. cloud computing, push services, user authentication, etc.) with very little configuration or setup. From big-name brands to indie shops, Parse was the obvious choice to accelerate production of MVPs, small to medium scale applications, or specific features of large scale applications. SaaS systems are often ideal for prototyping and personal projects, but for large, custom applications that company environment depends on, building own server stack is worth the extra time and effort. Parse isn’t the only player in the SaaS (Software as a Service) industry. Amazon, Google and Microsoft (and numerous other startups) now offer very similar tools for developers. The idea behind using a service like Parse, however, has always been that developers could avoid dealing with servers, so it remains to be seen how many of its current users will make this switch.