Use client-side MVC/MVVM patterns with MVC server-side pattern

Question

Considering the most popular MVC/MVVM client-side patterns (like Knockout.js, Angular.js, Ember.js, and others), I have one great doubt:

Also considering the modeling redundance in both sides, what is the advantages and disvantages to use those client-side patterns with MVC server-side patterns?

Answer 1

Ten months later after this question, I have used the both patterns inside the same application.

The only problem was the need to map the models twice.

MVC (ASP.NET MVC 4 Web API)

The most important resource was the routes.

• Models were created to database interactions and as arguments for controllers' actions.
• Controllers were created to manipulate the API requisitions and to render the views.
• Views were not modeled with server-side models, but all the resources of Partial Views and Sections.

MVVM (Knockout.js)

• Models were created with the same properties as the server-side models.
• Views were binded with models' properties, and decreased a lot of the views' size.
• View-models were created with the values provided from API methods.

Overall, the MVC combination with MVVM were very useful, but it needed a big expertise and knowledge. Patience is required too, because you need to think about the responsibilites of each application layer.

Answer 2

• advantages
  • This can rock.
• disvantages
  • You can screw it.

Seriously. Making use of transporting part of the frontend logic into the browser can boost your application development why you keep more strict data-processing encapsulated on server-side.

This is basically layering. Two layers, the one above talks with the one below and vice-versa:

[client] <--> [server]

You normally exchange value objects in a lightweight serialization format like Json between the two.

This can fairly well map what users expect in a useful structure while domain objects on server-side could not be that detailed.

However, the real power will be if the server-side is not in written in javascript at some certain point because I think you can not create well domain objects there. Consider Scala (or something similar expressive) then if you run into that issue.

Answer 3

I struggled with how to answer this question... hopefully this helps, even if it is in a round-about way.

While some of the pros/cons have already been stated, I think the best rundown is in this answer.

For me, the biggest advantage to using client-side logic is the rich UI aspect.

But the key part of your question seems to be "model redundancy" (I'd call it duplicated logic, or at least having potential for duplicated logic). In my opinion, that is a problem which may exist independently of the pros/cons in the previous link.

So first of all, I think that the decision of whether or not to use a client-side framework should be made based on the well-documented pros and cons. Once that decision is made, the associated problems can be solved.

Lets assume you are using some sort of server-side framework/platform, as well as a client-side framework to provide a little bit of UI interactivity. Now there is a problem with where to put the model logic: on the client, server, or both.

One way to solve the problem is to define your model logic in only the client or the server. Then you have no code duplication, but it affects some of the higher-level pros/cons.

For example, if your model logic is 100% server-side, you lose some of the interactive part of the UI. Or, you are constantly throwing the model to/from the server, which will have a few cons.

If your model logic is 100% client-side, you could suffer performance problems, depending on the size of your view / model. This is one of the reasons Twitter is moving to a server-side processing model.

Then there is "both"... having model logic exist in both the client and the server. I think this is the best solution, as long as no logic is duplicated.

For example, on a shopping cart page, you may recalculate the cost of an order based on the price of a product, and a user-editable quantity box. I think this logic should only exist on the client. Other model properties that do not change once loaded are probably fine hosted on the server.

There's a lot of gray area here... I struggle with putting all the eggs in one basket. For example, choosing a client-side framework, creating a lot of client-side logic, and then [hypothetically] running into problems with performance, browser support, or something like that. Now you may want to tweak a page or two for performance (like move it server-side, a la Twitter). But I think being smart about how you structure your code will help mitigate that issue. If your code is maintainable and clean, moving logic from client to server won't be difficult.

Answer 4

The fact you an incorporate a MVVM model into an already implemented MVC framework is also a great thing, we recently added knockout to some new project pages to fit with in an already outdated MVC framework (old pages, not the framework itself).

I think MVVM is fantastic as the above answer states it provides an exceptional user experience with extremely fast response times, you can hide your validation calls in the backround with out slowing them down and its intuitive.

The pain however is that it is VERY hard to unit test and you can get some extremely LARGE javascript files, also the extra coding we've had to do as our legacy systems still run on IE6 is ridiculous.

But MVVM and MVC don't have to be used exclusively on there own, we use both. But having 3 levels of validation is something that still bugs me.

Answer 5

The advantage is that the client side patterns are applicable at the client where the server has no direct reach. If you're building a rich, interactive HTML UI then use client side MVVM. Server side MVC may still be relevant in that case for delivering appropriate content to the client. For example, the ASP.NET WebAPI is a framework for creating HTTP APIs which has a similar controller architecture to the ASP.NET MVC framework. The API implemented with this framework may be called by client side code resulting in MVC on the server side and MVVM on the client side. Normally, when using MVC server side and MVVM client side, the responsibilities of the respective sides are very different and thus there is no redundancy.