Error getting theme layout

MVC Doesn’t Always Mean ORM

Posted @ 12:23 pm by Lee Springer | Category: Strategy, Web Development Process | 0 Comments

In the world of web development there has been a steady movement toward the monolithic open source MVC framework, especially for anyone engaged in developing prototypes or projects with aggressive schedules. It makes sense; the modern MVC frameworks such as Ruby On Rails, Symfony, Django, and many others were constructed to make the developer’s life easier. They provide a suite of services: database drivers, object relational mapping, request and response controllers, and everything else one would need to take a set of requirements and turn it into something functional on the Web. Plus, to varying degrees, they provide developers with the ability to extend the platform with new feature sets that were not originally provided by the vendor—allowing the project team to make a platform choice and feel comfortable that it will meet future desires.

It’s changed how we approach developing web applications; the days of home built CMS platforms and frameworks to build websites has been in a steady decline in the agency setting. We no longer have to dedicate resources to internal product development and maintenance; in addition, most off-the-shelf platforms now have add-on support packages directly from the vendor. With all of these benefits it’s hard to argue against using an MVC framework. To oversimplify things: you build a schema, you generate some models, you create the needed queries, you write some controllers, you develop some templates, and voila you have a working prototype. The only problem is, without proper foresight and design, the MVC framework can become a huge stumbling block in the future.

Here is an example scenario: a project team is tasked to build the latest social network targeted to a community of very passionate coffee drinkers. The requirements are analyzed and it is decided the application will be built on the PHP based Symfony framework. The team works diligently for a couple of months and produces a highly functional prototype, creating the Coffee Social Network web application. So far, everything looks great. The launch is a huge success and now the team is asked to build a mobile application and a partner API to expose all of the fantastic data that the Coffee Social Network is generating. Ok, doesn’t sound like a huge problem right? But, the Coffee Social Network has hired a team of developers who don’t really like working in PHP, they have concerns that it will no longer scale appropriately and would like all new development to be written in Python. In fact, they eventually would like to port the original prototype over as to Python as well. Their schedule, due to marketing commitments, calls for the new apps to launch before any rewrites are performed.

It’s easy at this point to just move on and build the new projects in a Python framework such as Django; however, herein lays the problem, there are now two development languages and multiple applications attempting to interact with one data set. There are a lot of options to address this particular scenario and they all have unique pros and cons. The point is, had we taken a moment back in our original project to design a robust service-oriented architecture, the problems of coordinating these applications could have been mitigated.

Let’s rewind back to the design phase of our original project and pretend like we don’t know what the future holds for Coffee Social Network. Instead of just using the ORM and various data models provided by the Symfony framework directly in the application, the developers decide to build a RESTful data access API first and foremost. All of the logic that typically is in the model layer of our MVC is put into our API application and any page of the website that interacts with data makes calls to the API from within the website application’s controller layer. The added effort to do this is not trivial, but it is minimal. The end result of this design is now delivery of a data access API and a website application that interacts with the API.

Now when Coffee Social Network meets with wild success and makes the request for more applications and exposure of data, no problem. Now when Coffee Social Network requests all future development be in languages differing from the original project, it’s just a matter of pointing the new applications to the API. By creating a more service-oriented architecture around how the applications interact with data, the future benefits vastly outweigh the slight increase of scope to develop the data API.

It doesn’t end there either. Anywhere that an application provides a specific service that can be encapsulated, such as authentication or data access, it’s worth looking at the benefits of migrating that functionality into a self-contained interface. By doing so, the entire environment of applications benefits from not having to have redundant functionality and each service can be scaled independently of each other, potentially providing a cost savings to the business.

Service-oriented architecture can be applied to any application, not just those built with MVC frameworks. I love MVC frameworks and all they have allowed us, as developers, to do within aggressive schedules and rapidly changing projects. The reason that I call them out here specifically is that they provide an environment in which it’s so easy to either generate or author code to interact with data directly, so sometimes we forgot to stop and see if it is the right thing to do. Any project where the business’s value is in their data can only benefit from a data access API.

 

Author: Lee Springer is the Technical Director of PHP Engineering at SolutionSet. 

Leave a reply

Error getting theme layout