Would this constitute MVC - even in a very loose sense?

Question

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.

Answer 1

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.

Answer 2

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:

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.

Answer 3

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 :)