I've been working on a kind of CRM for the sales guys in our office - not as a job role but as a spare time task type of thing - I don't claim to be a developer or anything like that, but I would definitely like to pursue a career as a web developer down the line, I just think I need a much stronger understanding of OOP principles and design patterns such as MVC before I could even consider it.

Basically the way I've developed it each section of the App is a html page, that uses jQuery to listen for events, which then sends ajax requests to the server, which are then redirected to class methods that will perform usually simple CRUD tasks, and send back a JSON response to the client which will then be reflected on the page - would that constitute mvc even in a loose sense, as presentation is completely seperate from things like database interaction and theres a go-between to interact between the two?

Like I say i'm in the very early stages of grappling the comprehension of MVC as a whole so any thoughts would be appreciated, thanks.

  • 12
    offtopic, but you know more about programming then half the web developers I know... Aug 2, 2012 at 17:38
  • 2
    Agreed with above comment - if web development is your ambition you're ready to go.
    – MattDavey
    Aug 2, 2012 at 18:45
  • lol, thank you! (I think, either that or it was a damning indictment towards web developers :P) like I say i'd love to pursue a career in it but as i'm self taught and havnt got any formal qual's it's hard to even get an interview - so I want to really know the water before I dip my toe in the pool so to speak Aug 2, 2012 at 18:45
  • 4
    It was also an indictment towards web developers lol. Don't let that stop you - I'm also self taught with zero qual's and I'm now entering my seventh year as a professional.
    – MattDavey
    Aug 2, 2012 at 18:46
  • yap, this looks quite like MVC
    – superM
    Aug 2, 2012 at 18:56

3 Answers 3


Certainly sounds like a good design and not a million miles from MVC.

sends ... requests to the server, which are then redirected to class methods

This is how a controller works in MVC. It is unclear, from your description, whether your model is separated from the controller. If the controller then passes its CRUD operations onto another class (eg. Customer.update(customerData)), and simply handles the request-response action then I would suggest you probably have the M and C in place -- albeit in a simplistic way.

each section of the App is a html page, ... and send back a JSON response to the client

Those are two common view types in MVC frameworks. And you've certainly created that level of abstraction, which is great.

Nowadays there are expectations of an MVC framework that don't necessarily fall into the MVC pattern. For example, to make it a "proper" MVC framework, you'd have to be able to return data from the controller, along with an indicator of which view type (and perhaps view template) you want the framework to build from that data.

So I would say that you've not necessarily created an MVC framework but you are following something approximating the MVC pattern.

Perhaps a more accurate term for what you're doing though is SOA or service-oriented architecture.

  • I've +1'd both you and Vain Fellowman mainly for pointing out alternatives to MVC for me to get reading about - as I think someone rightly pointed out MVC seems to be abit of a buzzword at the moment (probably rightly so) but speaking as someone new to design architectural patterns it's great to see what alternatives are available and suit my inherent design tendancies without being treated as a pariah. Thanks again! Aug 3, 2012 at 11:04

Your solution is not classical MVC in my opinion, it's far better. What you have, my young Padawan, is more like a SOA approach.

I personally like this style of architecture. In the Business Logic Tier, the Service-Oriented Architecture (SOA) message is being heard. With its loose coupling and removal of implicit dependencies, the SOA model yields flexibility and uniformity through the specification of a definite Service Interface, which hides domain models and implementation technologies.

Unfortunately, no such clear architectural blueprint exists for the Presentation Tier. What does industry best practice say about developing the front-end of an application? What is the best way to connect the front-end neatly into the Service Interface?

Classical MVC suffers (imho) from at least three major architectural flaws:

  1. It does not respect data, the data sent across the wire is highly presentation-oriented, marked-up data.
  2. Data interchange and presentation logic are tightly coupled. It is not possible to move through the steps of the Presentation Flow without initiating what amounts to Data Interchange operations. Web pages are displayed in response to GET and POST requests sent by the browser. Even worse, every Data Interchange operation initiated by the browser willy-nilly forces a Presentation Flow. An infamous result of this tight coupling is the "browser back-button problem".
  3. The third flaw is that the web model is request/response. It does not support peer-to-peer interaction styles that are required for server event notification.

At this juncture, one would be tempted to conclude that AJAX is the answer to these problems. Unfortunately, AJAX itself is just a raw capability and not a prescriptive model. It is possible to use AJAX and still come up with a horrible hybrid model where the web server continues to drive Presentation Flow in response to Data Interchange operations, and the AJAX interaction just hangs off to one side, so to speak.

The one model, that helps me most, is nevertheless based on MVC. MVC on server side, and on client side. The view on the server is the model in the client application, so to speak. An illustration:

MVC on client and server

Your application seems to follow this principle roughly. You probably had a hard time to come up with a good structure in your HTML and JS. Try to look at it with this approach. Your client Model is the server side view, your JSON data. Your event bindings and stuff is your Controller. The HTML is your View. Try to separate events and UI logic from data interchange, and you will find a very powerful way of creating web applications.


Looks more like a 3-tier system, where the view tier is client-side, the business-logic tier is in the services and data storage is in the RDBM. (MVC evolved out of 3-tier/3-layer designs)

You should know that MVC is just a very popular buzzword right now, like 3-tier or n-tier used to be up until 3-5 years ago. Don't try to put it on your resume just so it looks like everyone else's. N-tier app looks cooler for big enterprisie teams :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.