Procedural Vs MVC Programming

 

 

I am digital all-rounder Matt Rhys-Davies, and I’m gracing this page today to provide my brief thoughts on web application development and which side of the fence I sit in regards to the conflict over MVC and Procedural programming techniques.

As no doubt you will not be aware of my existence, here’s a quick introduction. As stated above — I’m Matt Rhys-Davies — I originally began my professional life as a developer, then progressed to content strategy, and now I finely balance myself between content strategy and web marketing in London — forever teetering between the two.

With both technical and commercial experience under my belt, I feel I am able to offer a unique perspective on the MVC Vs Procedural argument, that one can often find raging between marketers and developers, and that is: whichever one you — as a team — can agree on with being the most feasible.

There, I’ve said it. Perhaps not much of an insight but it’s true. From my experience marketers want to get something up as quick as possible to start monetizing the digital property (look at that terminology — slipped more into marketing than I thought), whereas developers want to produce a platform that is stable, scalable and with a code base that they can be proud of.

Well people, guess what? Compromise can be easy. Look at the project requirements, if it’s a simple CRUD application without the bells and whistles of a fully immersive user experience required, why make it heavy and more bloated than it needs to be. Like-wise, if it’s an all singing all dancing application with multiple points of access to data sources, why spend time repeating code functions when a single model can be produced that can then be instantiated from views all across the application.

Then of course, the key issue arises of where and how exactly do you host the site? Take a look at what sort of traffic and asynchronous actions that you anticipate the site will be receiving / coping with, and the intensity of the interactions, and go from there. If you’re expecting astronomical traffic from day one, then chances are you’d be best off on a dedicated server; the same applies if you’re going to be holding reams and reams of information. Essentially a dedicated server will present you with the hardware capabilities of powering a large scale web site efficiently in addition to providing onsite technical solutions, without having the huge initial outlay of purchasing

The beauty of dedicated hosting is the access to remarkably powerful, secure and high-capacity servers, without the hassle of setup, maintenance or the cost of purchase.

As your web property scales and your demands grow, you are then able to simply upgrade your server, move on to those that are bigger and better without having to buy or sell, old or new equipment.

Always bear in mind that the code-base of your application should be thoroughly portable.Try not to tie any application functions or performance into your server behaviors where possible.

If you start to rely on any server-side configs doing your routing (besides the .htaccess file), when you go to pick up your code base and move across to a new server you’ll find yourself in a whole heap of non-needed re-configurations. The key is to treat your server and your application as two separate, independent entities.

So, whilst this may not be a ground-breakingly insightful article to some, it is something that is looked over by most. Reach a compromise on production time frame, budget constraints and man hours, in addition to projected traffic and server loads, and then compromise on power and spending. Make sure that as developers you are happy, and as marketers you are happy. The end goal is to make money from the site, but don’t tear apart the team in the process, explore your options, research them, and then discuss.

Happy building!

This is a post written by Matt Rhys-Davies.