We’ve been developing a PVC architecture for a little while now, and there were some things we’ve found which are less intuitive or less convenient than using an MVC architecture. For those not familiar, here’s a basic rundown of Model – View – Controller and Proxy – View – Controller .
The tl;dr version is that PVC is the same as MVC, except instead of having real model classes, you have a proxy that contacts an API with all the model logic. This ensures a complete separation of model code and business logic from presentation and controller code. As engineers, we like separation and modularity – so what are some problems with this architecture?
The most obvious is the extra work involved. Now instead of maintaining one application, you are maintaining two applications. You now have to pull two repos every day – one for the presentation layer and one for the api layer – any time you want to add features that affect both presentation and model. For web applications, that covers most important features. This violates loose coupling and adds extra work.
A less obvious issue is the lack of tools to implement this kind of architecture. Abstracting the interactions between application controllers and databases is a largely solved problem. Libraries such as ActiveRecord, Kohana ORM, Mongoid and others exists to provide robust interfaces between your data and your controllers. With APIs, however, assumptions about the nature of the API cannot be coded into a library. Twitter’s API is different from del.icio.us' API is different from Compete’s API; all of which are different from your API. So almost assuredly there are no robust interaction libraries for dealing with your internal API. This means things like auto-generating forms, error checking, batching and combining queries, and assigning relations between elements will have to be coded by you. We’re working on making this easier with libraries like ObjectStruct and HypertextClient but there’s quite a ways to go there.
Another less obvious issue is multiplicity in testing. Since you have to code your own API interactions to some degree, you have to test that code. This raises some additional questions – in testing your API client, do you mock out your API, or risk creating actual objects (which may have naming or other conflicts) on a staging API? If you mock out your API, how do you maintain and update your mocks? Also, when testing your front-end applications, do you use a mocked API or contact a staging API? Or do you set up more infrastructure to provide clean test databases for each application’s API layer?
In summary, if you’re going to build a PVC architecture, you’re going to be doing a lot of work to make sure all the components fit together in a way that’s tested and secure. This could be worth it – if you have many, many frontend applications, or if you want to allow direct access to an API for third-party clients, having robust individual layers may be to your organization’s advantage. Otherwise, think carefully about whether this is a good approach.