An architecture for almost complete JavaScript-based web applications?

I know that MVC is highly开发者_如何学编程 acclaimed for PHP applications, but I am not sure at all that it fits in JavaScript. If you think otherwise, then please explain how and where you handle common scenarios like AJAX requests, data saving (offline storage), presentation, how do you handle controller logic (do you have a front controller?), and so forth.

What about Model-View-Presentation?

I am using ExtJS and using the server only for permanent data storage.

If you're planning on coding your UI purely with JavaScript, you could think your PHP end of things as more of a web service or an API.

Basically your View would be the Ext JS stuff you write in JS. To work with your data, the Ext frontend would perform requests to your "service". Basically you would have a sort of model-controller architecture on your server, where the job of the controller would be to process requests and output JSON (for consumption by your Ext frontend)

Essentially, the "view" in your backend would simply be output from json_encode, which is then consumed by your actual Ext based view.

In JS, you can have controllers depending on what sort of stuff you're doing. If you're just displaying data from the server, you may not require much separate logic. If you're doing some more complex processing, it may be useful to separate the code into a separate controller and view.

It's mostly up to how much you want to separate the logic.

When writing almost complete javascript applications you can think of MVC as:

• View: The DOM
• Controller: Your JavaScript
• Model: Combination of JavaScript Ajax Calls and their PHP (or whatever) backend counterparts

PureMVC is an extremely cool MVC framework. You should check it out.

I'm using the same architecture: predominantly ExtJS on top of a PHP back-end.

My solution:

• Strict JSON-RPC communication with the server. The server-side API is clean enough that it's also our third-party interfacing API. Forcing the API to be the same one that third-party interfaces use makes you keep the server-side code clean and minimal, which is good for security and performance.
• Heavily componentized architecture, split into modules that group components (Ext.Panel derivatives usually). Each component knows how to request its initial configuration and data via JSON-RPC calls, render itself, and save its state if necessary. I try to keep the communication between components clean and documented.
• On-demand architecture, loading in additional components via javascript files as needed. The entire code is designed to be initialized via callbacks, so that components can load their dependancies from the server and render only an empty placeholder before they initialize themselves.

Individual components may employ an MVC pattern, where it makes sense. Ext tends to encourage MVC anyway, separating data out into stores and having a separate rendering infrastructure (although it does blend controller logic with the rendered components).

I'm not sure I understand where you are going with your question, but I'll give it a shot.

MVC is an architectural pattern which in its essence means keeping the data model, the controller and the UI loosely coupled as much as possible.

You are trying to boil it down to the technological level, and it's not really making any sense. You can do proper MVC with a good framework. Just to make things clear, plain-vanilla PHP does not give you good MVC support. A good framework, such as CakePHP or CodeIgniter - will.

JS is just a nice way to enrich the client-side experience. Meaning that unless you are doing server-side JS, the only place you will have JS is in the view itself. AJAX requests have nothing to do with MVC, per-se. Neither does data persistence. Unless you are implementing your own controller (and you better have a damn good reason to do so yourself), you shouldn't be worried about its internal logic.

Bottom line, if you want to do proper MVC, use a proper framework, and all will fall into place.