SOA与MVC - 何时使用

Question

我读过这个主题,但仍然没有完整的图片,我真的很感谢你对下一个问题的回答:

• 应该使用什么类型的应用程序SOA方法(从服务器端获取JSON并使用javascript框架在客户端生成html,如knockout js,angular js等),以及服务器端的ASP.net MVC - 就像替代方案一样体系结构方法(完全在服务器端生成页面并返回视图).
  例如,对于具有丰富客户端逻辑的最后一个SPA,wcf服务+ knockout js(客户端MVVM)提供了很好的结果.但是哪种方法更适合CRUD应用程序(例如,几个表用于添加,更新使用中的不同用户角色的数据).

Answer 1

SOA不仅仅是将JSON发送到Web客户端.

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

但是,随着系统的发展,有些东西你会发现它们不适合这个模型:长时间运行的批处理过程会锁定应用程序或网页,计划的作业不仅仅涉及数据库服务器,涉及生活在外部源中的数据的过程,或者在数据库运行时使数据库陷入困境的复杂报告.此时,您需要考虑添加应用程序服务器来处理其中的一些任务.应用程序服务器可以从客户端获取部分工作负载.它也可以采取一定的负荷过什么是可能这个时候是一个过度工作的数据库,使得应用程序服务器的请求或原始数据移动到和来自DB,和你的应用程序请求/提交转化数据,并从应用程序服务器.

随着系统的不断发展,您还会发现系统的不同部分在维护事物时会在其他地方产生意外的副作用.即使是简单的增强功能也会变得越来越复杂.开发速度变慢,错误数量增加.应用程序服务器现在成为集中设计工作的好地方,如何确保一个区域的更改在其他任何地方都具有预期的后果(并且只有预期的后果).

从一开始,SOA真正的本质就是采用该应用服务器(可能会使用json而不是http,但也可能提供完全不同的接口,甚至可以自动转换为多种数据传输技术)并强制实施所有,而不是只是一些,数据库访问通过这个应用服务器:服务层.

一旦强制执行此访问,并且没有其他任何内容直接与数据库直接对话(至少没有特别说明的内容),该层也成为开始实施业务规则和系统逻辑的好地方.它允许您在这里编写传统的应用程序样式代码,这些代码比sql更易于使用源代码控制,并且将在使用该系统的任何应用程序之间自动共享.代码都存在于大致相同的位置,因此通过系统模拟更改及其效果更容易.作为奖励,该层通常很容易扩展到多个冗余服务器,因此这可以成为改善和管理大型应用程序的性能和可靠性的一种方法.在后端,它还可以通过简化和集中使用redis等数据库缓存工具的工作来提高性能,从而更容易让专用DBA参与性能调优,并帮助您集中访问位于多个位置的数据.

此时,您的MVC网站只是一个连接到SOA系统中的应用程序服务器的应用程序.您可能还在某些桌面上安装了旧版客户端 - 服务器应用程序,或者您的MVC应用程序可能面临公开销售,而实际销售和支持代表使用完全不同的东西,计费使用不同的应用程序,订单履行或采购还有另一个界面...但他们都在同一服务层谈话.这里的另一个优势是,这个服务层可以更容易从多个来源的数据来拉,所以如果你的生产系统需要来自外部系统的物料可用性信息,服务层可以知道如何去发现和前端代码没有按不得不知道这些数据来自任何特殊的地方.

所有这一切的重点在于它不是/或在这里的情况.如果您有SOA,则可以在系统的一个级别使用MVC,并且SOA的服务层提供的接口将确定您的MVC模型的一些内容以及控制器的行为方式.如果你没有SOA,那么MVC恰好可以构建整个堆栈,从数据库到表示,并且实际上工作使得模型成为更大服务层的缩影.

那么,关于何时使用JSON与何时使用ASP.Net MVC的问题需要一个新的形式.ASP.Net MVC可以是SOA体系结构的一部分,提供JSON数据的服务框架通常使用客户端MVC库实现.你真的想知道什么时候在客户端做更多比在服务器端做更多更合适.老实说,我认为这主要是个人偏好,但你需要注意的是权衡取舍.

在客户端做更多工作对于提高性能和可扩展性非常有用,因为它可以将应用程序的工作负载分散到所有用户的计算机系统中,并且可以减少通过往返Web服务器或应用程序服务器所引入的延迟.

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