asp.net-mvc – SOA vs MVC – 何时使用

想象一下，您有一个数据库驱动的软件系统，例如销售，库存，报告等业务。大多数系统开始很小，只是一个客户端或Web应用程序直接与数据库进行交谈，没关系。

然而，随着系统的增长，您会发现在这个模型中不合适的一些事情：长期运行的批处理程序锁定应用程序或网页，调度的工作不仅仅涉及数据库服务器，涉及数据生活在外部来源的过程，或复杂的报告，这些报告在您的数据库运行时遭到破坏。此时，您将考虑添加应用程序服务器来处理其中的某些任务。应用程序服务器可以将一些工作负载从客户机上卸载。它也可能需要某些负载关闭这个时候可能是一个过度工作的数据库，使应用程序服务器请求或移动原始数据到和从数据库，您的应用程序请求/提交转换数据到和从应用程序服务器。

随着系统越来越多，您还会发现系统的不同部分在您维护事情时会出现意想不到的副作用。即使简单的增强功能也变得越来越复杂。开发速度减慢，bug数量增加。现在，应用程序服务器成为集中设计工作的一个好地方，即如何确保一个区域的更改具有预期的后果(只有预期的后果)在其他地方。

首先，SOA真的是采用该应用程序服务器(可能会发生在http上使用json，但也可能提供完全不同的界面，甚至可以在多种数据传输技术之间自动翻译)并执行所有的只是一些，数据库访问通过这个应用服务器：服务层。

一旦这种访问被强制执行，并且没有任何其他事情直接与数据库进行直接交谈(至少没有什么是没有具体说明的)，该层也将成为启动实施业务规则和系统逻辑的好地方。它允许您在这里编写传统的应用程序样式代码，它比sql更容易使用源代码控制，并将自动在使用系统的任何应用程序之间共享。代码都生活在相同的地方，因此通过系统更容易地对变更及其影响进行建模。作为一个奖励，该层通常很容易扩展到多个冗余服务器，因此这可以成为改进和管理大型应用程序的性能和可靠性的一种方式。在后端，它还可以通过简化和集中使用诸如redis之类的数据库缓存工具来提高性能，并帮助您集中访问生活在多个地方的数据。

此时，您的MVC网站只是一个连接到SOA系统中的应用程序服务器的应用程序。您还可以在某些桌面上安装旧版客户端 – 服务器应用程序，或者您的MVC应用程序可能面临公共销售，而实际销售和支持代表使用完全不同的内容，计费使用不同的应用程序，订单执行或采购还有另一个界面…但他们都谈到同一个服务层。这里的一个额外的优点是，该服务层可以更容易地从多个来源获取数据，因此如果您的制造系统需要来自外部系统的物料可用性信息，则服务层可以知道如何去找到和前端代码不得不知道这些数据来自任何地方。

所有这一切的观点是，这不是一个/或这里的情况。如果您有一个SOA，您可以在系统的一个级别使用MVC，而SOA服务层提供的界面将决定您的MVC模型的一些内容以及控制器的运行方式。如果您没有SOA，MVC就可以在构建整个堆栈(从数据库到演示文稿)方面工作得很好，实际上这样做可以使模型成为更大服务层的缩影。

那么问题是什么时候使用JSON和什么时候使用ASP.Net MVC需要一个新的形式。 ASP.Net MVC可以作为SOA架构的一部分，提供JSON数据的服务框架通常使用客户端MVC库来实现。你真的想知道什么时候更适合在客户端做更多的事情，而在服务器端做更多的事情。老实说，我认为这主要是个人偏好，但你应该注意的是权衡。

更多的工作客户端对于性能和可扩展性来说可以是非常好的，因为它将您的应用程序的工作负载传播到所有用户的计算机系统之间，并且可以减少通过向Web服务器或应用程序服务器进行往返所引入的延迟。

另一方面，做更多的工作服务器端对于避免在较慢的公共互联网链接上传输较大的数据集的延迟是有益的，可以使其更容易满足诸如美国残疾人法案可访问性要求之类的合规性要求，其中过多的JavaScript可能导致可访问浏览器或将数据推送到客户端系统的问题可能构成隐私或安全风险，并且当更多的处理发生在同一层内时，可以使开发，部署和维护新代码更容易。