我已经阅读了这个主题，但仍然没有完整的图片，我非常感谢您对下一个问题的回答：
SOA 不仅仅是将 JSON 发送到 Web 客户端。
想象一下，您的企业拥有一个数据库驱动的软件系统，用于销售、库存、报告等。大多数系统开始时都很小，只有一个客户端或 Web 应用程序直接与数据库对话……这没关系。
但是，随着系统的增长，您会发现有些东西不适合此模型：锁定应用程序或网页的长时间运行的批处理，不仅涉及数据库服务器的计划作业，涉及生活在外部来源中的数据的过程，或在运行时使您的数据库陷入困境的复杂报告。
此时，您需要考虑添加一个应用程序服务器来处理其中一些任务。应用程序服务器可以减轻您的客户端的部分工作负载。它还可以减轻此时可能是过度工作的数据库的某些负载，例如应用程序服务器请求或将原始数据移入和移出数据库，而面向用户的客户端请求/提交转换后的数据到和从应用服务器。
随着系统的进一步发展，您还会发现系统的不同部分在您维护事物时会在其他地方产生意想不到的副作用。即使是简单的增强功能也变得越来越难以完成。开发速度放缓，错误数量增加。应用程序服务器现在成为一个很好的地方，可以集中设计工作，以确保一个领域的变化在其他地方产生预期的后果（并且只有预期的后果）。
起初，SOA 的真正含义是采用该应用程序服务器（它可能碰巧使用 json over http，但也可能提供完全不同的接口，甚至在几种数据传输技术之间自动转换）并强制执行all，而不是只是一些，数据库访问通过这个应用服务器：服务层。
一旦强制执行此访问，并且不再与数据库直接对话（至少，没有特别说明的内容），该层也成为开始执行业务规则和系统逻辑的好地方。它允许您在这里编写传统的应用程序风格的代码，这些代码比 sql 更易于使用源代码控制，并且将自动在使用系统的任何应用程序之间共享。代码都在同一个地方，因此更容易通过系统对更改及其影响进行建模。
作为奖励，这一层通常很容易扩展到多个冗余服务器，尤其是与传统的关系数据库服务器相比。结果是扩展应用程序服务器可以成为改进和管理大型应用程序的性能和可靠性的一种方式。在后端，它还可以通过简化和集中使用 Redis 等数据库缓存工具的工作来提高性能，使专门的 DBA 更容易参与性能调整，并帮助您集中访问位于多个位置的数据。
此时，您的 MVC 网站只是一个连接到 SOA 系统中的应用程序服务器的应用程序。您可能还在某些桌面上安装了旧的客户端-服务器应用程序，或者您的 MVC 应用程序可能面向公开销售，而实际销售和支持代表使用完全不同的东西，计费使用不同的应用程序，订单履行或采购有另一个界面...但它们都与同一个服务层通信。这里的另一个优势是该服务层可以更轻松地从多个来源提取数据，因此如果您的制造系统需要来自外部系统的材料可用性信息，则服务层可以知道如何找到它而前端代码不需要不必知道这些数据来自任何特殊的地方。
所有这一切的重点是它不是非此即彼的情况。如果您有 SOA，您可以在系统的某一层使用 MVC，SOA 的服务层提供的接口将决定您的 MVC 模型的一些外观以及控制器的行为方式。如果您没有 SOA，MVC 在构建从数据库到表示的整个堆栈时恰好可以正常工作，并且实际上可以使模型成为更大服务层的缩影。
那么，何时使用 JSON 与何时使用 ASP.Net MVC 的问题呈现出一种新的形式。ASP.Net MVC 可以是 SOA 架构的一部分，提供 JSON 数据的服务框架通常使用客户端 MVC 库来实现。你真的想知道什么时候在客户端做更多的事情比在服务器端做更多的事情更合适。老实说，我认为这主要是个人喜好，但是您应该注意一些权衡。
做更多的工作客户端可以很好地提高性能和可伸缩性，因为它将应用程序的一些工作负载分散到用户的计算机系统中，并且可以减少通过往返 Web 服务器或应用程序服务器引入的延迟。
另一方面，在服务器端做更多的工作有利于避免通过较慢的公共互联网链接传输更大的数据集时的延迟，可以更容易满足美国残疾人法案可访问性要求等合规性要求，其中过多的 javascript 可能会导致可访问浏览器或将数据推送到客户端系统的问题可能会构成隐私或安全风险，并且当更多处理发生在同一层内时，可以更容易地开发、部署和维护新代码。
就架构的 SOA 部分而言，客户端 MV*（MVC、MVP、MVVM 等）架构和服务器端 MV* 架构是相同的。
模型是您与服务通信并从各种服务获取数据的地方。客户端 MV* 和服务器端之间的选择是正交的。