Search code examples
javascriptangularjsbackbone.jsmodel-view-controllerthree-tier

What are the reasons I would need an MVC model on the browser client for a server based application?

Assumptions:

  • I have a banking app with a Java-style web server.
  • The Client side is written in JS with backbone and other plugins. (The developers are fans of Angular, but they're not using that).

My JavaScript developers have come to me and said "X is impossible because of the way we do the MVC in the browser."

Now I'm fine with an MVC on the server side; we already have that. But when the JavaScript guys want to have an MVC on the client, it feels like we're keeping a state about the customer's experience in two different places. I think it's simpler to keep in one place.

I'm familiar with the 'three-tier' architectures of the 90s - with a database tier, a tier for transaction management, and another tier for customer interaction. We moved away from that because it was horrible.

I'm also familiar with running server-side apps in Node.js. To me - it makes sense to have a server-side MVC in this scenario.

My question is: What are the reasons I would need an MVC model on the browser client for a server-based application?

Solution

  • Totally agree with New Dev answer.

    In the server, you handle state in the form of current logged user, data, and so on.

    In the client, your state will be the application state (which "page" or screen they're on, which is the currently selected item in a list, and so on).

    Think of the server (if it's implemented using a REST API) as your database+authentication, and your client as a desktop app (the UI state is what you're handling). This way of thinking really helped me initially with Backbone. Translate your SELECT to a collection.fetch, INSERT/UPDATE to a model.save() and DELETE to a model.destroy(). In a SPA, your API is your database and your SQL is HTTP and JSON -and probably more, but it may help to think it that way.