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:
- It does not respect data, the data sent across the wire is highly presentation-oriented, marked-up data.
- 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".
- 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.