SOA vs MVC - when to use
I'v read this topic but still have not complete picture and I would really appreciate your answer to the next question:
- for what type of application should be used SOA approach (get JSON from server side and generate html on the client side using javascript framework,
like knockout js, angular js and so on), and ASP.net MVC on the server side - like alternative architecture approach (generate pages totally on the server side and return views as result).
For example, for last SPA with rich client side logic wcf services + knockout js (client side MVVM) provided great result. But what approach will be better suited for CRUD application (for instance, several tables for adding, updating data with different user roles in use).
Answer
SOA is about a lot more than just sending JSON to a web client.
Imagine you have a business with a database-driven software system for things like sales, inventory, reporting, etc. Most systems start out small, with just a client or web app talking directly to the database... and that's okay.
However, as the system grows, there are some things you'll find that don't fit well inside this model: long-running batch processes that lock up the app or web page, scheduled jobs that involve more than just the database server, processes involving data living in outside sources, or complex reports that bog down your DB while they run. At this point, you'll want to think about adding an application server to handle some of these tasks. An application server can take some of that workload off of your clients. It can also take certain loads off what is likely by this time to be an over-worked database, such that the application server requests or moves raw data to and from the DB, and your application requests/submits transformed data to and from the application server.
As the system grows even more, you'll also find that different parts of the system have unexpected side effects elsewhere as you maintain things. Even simple enhancements become more and more complicated to complete. Development slows, and bug counts increase. The application server now becomes a great place to centralize design efforts on how to make sure a change in one area has the expected consequences (and only the expected consequences) everywhere else.
At its outset, what an SOA really is, then, is taking that application server (which might happen to use json over http, but might also offer a completely different interface or even automatically translate among several data transport technologies) and enforcing all, not just some, database access goes through this application server: the service layer.
Once this access is enforced, and nothing else talks directly to the database any more (at least, nothing that's not specifically accounted for), the layer also becomes a great place to start enforcing business rules and system logic. It allows you to write traditional application-style code here that's easier to use with source control than sql and will automatically be shared among any applications using the system. The code all lives in about the same place and so it's easier to model changes and their effects through the system. As a bonus, this layer is often very easy to scale out to multiple redundant servers, and so this can become a way to improve and manage performance and reliability of a large application. On the back-end, it can also improve performance by simplifying and centralizing efforts to use database caching tools like redis, making it easier to involve a dedicated DBA in performance tuning, and helping you centralize access to data that lives in multiple places.
At this point, your MVC web site is just one more app that connects to the application server in your SOA system. You might also have a legacy client-server app installed on some desktops, or your MVC app may be public sales facing while actual sales and support reps use something completely different, billing uses a different app, and order fulfillment or procurement have yet another interface ... but they all talk to the same service layer. An additional advantage here is that this service layer makes it easier to pull in data from multiple sources, so if your manufacturing system needs material availability information from an outside system, the service layer can know how to go find that and front-end code doesn't have to know this data came from anywhere special.
The point of all this is that it's not a case of either/or here. If you have an SOA, you can use MVC at one level of the system, and the interface provided by the SOA's service layer will determine some of what your MVC model looks like and how the controller behaves. If you don't have an SOA, MVC just happens to work okay at building the whole stack, from database to presentation, and in fact works such that the model becomes a microcosm for a larger service layer.
The question, then, of when to use JSON vs when to use ASP.Net MVC takes on a new form. ASP.Net MVC can be part of an SOA architecture, and service frameworks that offer JSON data are often implemented using client-side MVC libraries. You really want to know when it's more appropriate to do more on the client side vs more on the server side. Honestly, I think this is mostly personal preference, but there are trade-offs you should be aware of.
Doing more work client side can be great for performance and scalability, because it spreads the work-load of your application among all of your users' computers systems, and it can reduce latency introduced by making round trips to a web server or application server.
On the other hand, doing more work server side is good for avoiding latency in transferring larger data sets over slower public internet links, can make it easier to meet compliance requirements for things like the American Disabilities Act accessibility mandates, where too much javascript can cause problems with accessible browsers or pushing data to client systems may constitute a privacy or security risk, and can make it easier to develop, deploy, and maintain new code when more of the processing happens all within the same layer.