Wednesday, October 1, 2014

Why an Ideal MVC Framework Fails

One of the "Next Big Things" these days is the use an MVC framework for developing Web applications. There are a number of MVC frameworks out there including Backbone, Ember, and the rapidly growing Angular. 

Ideally these MVC frameworks are great, hook things together and any changes to the model (data) and all the views are updated based on the controller code. If there is changes to the model, the data is automatically updated on the server. This is the ideal case.

However, it assumes one critical thing, you have the access rights to CRUD data on the server. This is an extremely dangerous assumption.

In our iPhora security model, we assume the opposite and you do not have access rights to any data on the server. We do not trust anything and any request. We assume that you are trying to hack and inject. Your authorization is checked during each request. We looked at using Angular since it is the hot stuff of the MVC world and everyone seems to be using it. We also looked briefly at Backbone. However, these required us to hack and patch the code to do what we wanted it do. As a result, it would be hard to maintain in the future when new versions of Angular or Backbone comes out.

Since we have been using Dojo for awhile, we looked at a couple of Dojo-based MVC frameworks including Dojorama and the Dojox/MVC. These two also assumes an ideal MVC approach which is not what we wanted. Also Dojox/MVC is heavy.

Most of the MVC frameworks works well for simple applications and even more complexity applications. But for our iPhora applications like iPhora Touch, within one session, the user access rights and roles will vary constantly depending of the state and application the user is accessing. 

One thing that all these MVC frameworks lack is good documentation not on how to use it but documentation regarding the core architecture and functionality. You have to go through all the code and test and sometimes it is trial and error and assumptions. What a pain.

So we decided to create our own MVC framework using Dojo. The newer AMD approach for Dojo lends itself to the MVC approach.  Dojo already has core methods to handle MVC including dojo.store, dojo.stateful, dijit.watch/unwatch, and dojo.store.observeable. Also, don't forget the powerful dojo.subscribe and dojo.publish. We used the Dojorama project as a guideline and starting point. This MVC project is a good demonstration of the power of Dojo.

So where are we? Our initial MVC architecture is completed and we have modified our development tools to handle the new MVC approach. But, we expect more changes to come as we test.  The base core code is almost complete and will be ready for a test during the next couple of days. Our existing page-based JSON Restful services API will require some minor changes that are relatively easy to make. We are half way done in updating our existing iPhora Dojo/Bootstrap widgets to Dojo 1.10/Bootstrap 3.2 with MVC-based hooks. So stay tune for more updates.

5 comments:

Jesse Gallagher said...

Ah, I was thrown off by the title - you're talking specifically about client-side MVC frameworks, not MVC frameworks in general.

In any event, it is indeed crucial to not trust data from the client. Due to that, using the Domino REST API directly is a bad idea for this sort of thing (though it's perfect for an example, which is why it shows up in tutorials). What you really want to have is an API implemented on the server that does this sanity-checking regardless of the source - so all the validation, access control, etc. done on the server and then exposing a specific REST API.

It gets more complicated when you have to do the same validation twice in order to avoid having to round-trip everything all the time, but that's sort of the hassle of web development.

Domino Interface said...

Yes that is what our Restful API does and you can only GET and POST no PUT or DELETE, since I need to check you out before I let you do anything. You can simulate PUT and DELETE to be compatible with CRUD, put it really just a POST. The avoidance of double validation in the data model is tricky and that is what I am working on right now.

Jesse Gallagher said...

If you end up building it out further to the point where it makes sense to have it as a service in each DB via an OSGi plugin, I recommend giving Wink a look. It makes it pretty easy to construct web services with code for GET/POST/PUT/DELETE - it's what I use with my model-framework API, and I got the inspiration from the DAS code.

Domino Interface said...

Thanks for the info, I will take a look.

Domino Interface said...

Thanks for the info, I will take a look.