.NET MVC、 WebAPI、 WebService【ws】、MVVM、WCF、Remoting_mfc webapi webservice

mvc接口、webapi、webservice 对比

mvc和webapi区别：
1、MVC是建站的一种框架，倾向于返回用户的页面请求；api倾向于返回用户数据请求；
2、mvc直接继承System.Web.Mvc.Controller; 而webapi继承的是System.Web.Http.ApiController
3、MVC只能部署到IIS上，而webapi可以寄宿在不同的宿主上（寄宿的本质就是利用一个具体的应用程序为Web
Api提供一个运行的环境，并解决请求的接收和响应的回复），如Web Host，Self Host方式
4、接参数方式不一样：
mvc接口不管是get请求还是post请求都可以在方法名后面接参数形式，或者直接接对象方式，但是webapi接参
数方式有点复杂，get请求也可以直接在方法后面接到参数。
但是post请求
（1）1个参数的时候，可以用

$.ajax({
type: “post”,
url: “http://localhost:111/api/MyApi/SaveData”,
data: { “”: “test” },

接口里面用如下方式接受
[HttpPost]
public bool SaveData([FromBody]string NAME)
{
return true;
}
（2）两个以及两个以上的参数，是不能用方法明后加参数形式直接接收。
可以用实体方式（这种方法比较推荐。因为在手机端调用接口的时候更好的使用）
5、返回结果的区别：
mvc返回System.Web.Mvc.JsonResult(return Json(model,
System.Web.Mvc.JsonRequestBehavior.AllowGet))，在前段可以直接使用；而webapi想要直接使用，需要
返回JsonObject，否则需要json.parse（obj）转化
private JsonObject ModelToJson(Result result)
{
JsonObject obj = new JsonObject();
obj.Accumulate(“code”, result.code);
obj.Accumulate(“message”, result.message);
return obj;
}
备注：
1、在新建webapi的时候，必须要添加webapi 控制器类。。不能直接新建个类，，然后改成继承ApiController，否则是无效的webapi.
2、JsonObject 来源于 Maticsoft.Json.dll
其实用的多了。就会感觉两个并没有太大的区别。但是如果你只是为了处理数据的话，采用webapi是比较好的选
择，因为 MVC 框架负责的东西太多了，我们可以说它是一个重量级的框架,大型项目，就很臃肿，不易维护了，而webapi是个轻量级的框架。

webservice是remoting的一个特例 webservice用http，remoting同时支持tcp和http webservice用值传递，使用soap协议，remoting可以用引用传递，既可以使用xml又可以使用binary传递，效率比webservice高 webservice需要host在IIS上，remoting可以随便自己写个程序host 在局域网中一般使用remoting，在广域网中需要穿过防火墙的一般使用webservice remoting主要用在c/s结构里，webservice主要用在b/s结构上
其实现的原理并没有本质的区别，在应用开发层面上有以下区别： 1、Remoting可以灵活的定义其所基于的协议，如果定义为HTTP，则与Web Service就没有什么区别了，一般都喜欢定义为TCP，这样比Web Service稍为高 些 2、Remoting不是标准，而Web Service是标准； 3、Remoting一般需要通过一个WinForm或是Windows服务进行启动，而Web Service则需要IIS进行启动。 4、在VS.net开发环境中，专门对Web Service的调用进行了封装，用起来比Remoting方便
Remoting一般用在C/S的系统中，Web Service是用在B/S系统中 后者还是各语言的通用接口 相同之处就是都基于XML
为了能清楚地描述Web Service 和Remoting之间得区别,我打算从他们的体系结构上来说起: Web Service大体上分为5个层次: 1. Http传输信道 2. XML的数据格式 3. SOAP封装格式 4. WSDL的描述方式 5. UDDI
总体上来讲，.NET 下的 Web Service结构比较简单，也比较容易理解和应用： 一般来讲在.NET结构下的WebService应用都是基于.net framework以及IIS的架构之下，所以部署(Dispose)起来相对比较容易点. 从实现的角度来讲，
Web api
主要功能：
支持基于Http verb (GET, POST, PUT, DELETE)的CRUD (create, retrieve, update, delete)操作
请求的回复格式支持 JSON，XML，并且可以扩展添加其他格式。
.请求的回复通过Http Status Code表达不同含义，并且客户端可以通过Accept header来与服务器协商格式，例如你希望服务器返回JSON格式还是XML格
式
应用场景：
如果服务需要在http协议上，并且希望利用http协议的各种功能，
如果服务需要被各种客户端(特别是移动客户端)调用，选择Web API
WCF
主要功能：
分布式通信框架的集大成者
应用场景：
1.SOAP Services:这是因为WCF服务是基于消息的通讯机制，而它的消息是被封装为一个SOAP Envelope（SOAP 信封的）
2.WebHttp Services:是在传统的SOAP Services基础上的一个增强，它仍然是基于操作（Operation）的，只不过这些Operation可以直接通过Uri访问
到，而无需客户去编写一个特殊的客户端。(ps: 实质是webservice，用的最多的)
同时，WebHttp Services提供了两种不同的消息格式，第一种是XML，第二种是Json。这将更加有利于诸如Javascript这种客户端来访问服务。
要实现WebHttp，我们首先要添加一个引用
3.WCF Data Service:支持两种数据模型，一种是LINQ to SQL, 一种是ADO.NET Entity Frmawork。
4. Workflow Services：这是一个很有意思的服务。这是在.NET Framework 4.0中开始出现的，也就是随着Workflow Foundation升级到4.0之后，提
供了一种全新的服务类型，简单地来说，它是可以直接与Workflow Foundation(工作流）想结合的一种服务。
5.RIA Services：RIA的意思是，Rich Internet Application。在微软平台上，Silverlight就是RIA战略中的核心产品，所以很显然，RIA Service主要
就是为Silverlight服务的。这个是.NET Framework 4.0中才有的功能，并且还需要安装RIA Service Toolkit。
总结：
现在我们拥有了2个服务框架，一个基于RPC(远程过程调用(Remote Procedure Call) )机制的WCF和一个基于HTTP的ASP.NET Web Api。
在我们的开发实践中如何进行选择呢？ 可以参照知名互联网企业，无论是google，facebook,baidu,新浪还是腾讯。他们对外开放的接口都是基
于Http的Web API，在服务内部框架都是基于SOA架构设计的，通讯机制都是采用RPC机制的，例
如Google Protocol Buffers ，Facebook thift。 我们完全也可以这样搭配，在内部通讯采用WCF + Protobuf-NET，参看《WCF服务上应
用protobuf》，对外的服务采用ASP.NET WEB API。WCF的 TCP、Named Pipes，甚至UDP（在WCF 4.5中）绑定的性能要比HTTP强很多倍，这
里有一个几年前的微软的测试报告《WCF 性能基准报告》，对外提供的服务采用Web API同时也是一个业界标准问题，用WebAPI就很容易的跨越ios，android，wp等移动终端平台，同时有很成熟的OAuth 解决安全问题。
在.net平台下，有大量的技术让你创建一个HTTP服务，像Web Service，WCF，现在又出了Web API。在.net平台下，你有很多的选择来构建一
个HTTP Services。我分享一下我对Web Service、WCF以及Web API的看法。
Web Service
1、它是基于SOAP协议的，数据格式是XML
2、只支持HTTP协议
3、它不是开源的，但可以被任意一个了解XML的人使用
4、它只能部署在IIS上
WCF
1、这个也是基于SOAP的，数据格式是XML
2、这个是Web Service（ASMX）的进化版，可以支持各种各样的协议，像TCP，HTTP，HTTPS，Named Pipes, MSMQ.
3、WCF的主要问题是，它配置起来特别的繁琐
4、它不是开源的，但可以被任意一个了解XML的人使用
5、它可以部署应用程序中或者IIS上或者Windows服务中
WCF Rest
1、想使用WCF Rest service，你必须在WCF中使用webHttpBindings
2、它分别用[WebGet]和[WebInvoke]属性，实现了HTTP的GET和POST动词
3、要想使用其他的HTTP动词，你需要在IIS中做一些配置，使.svc文件可以接受这些动词的请求
4、使用WebGet通过参数传输数据，也需要配置。而且必须指定UriTemplate
5、它支持XML、JSON以及ATOM这些数据格式
Web API
1、这是一个简单的构建HTTP服务的新框架
2、在.net平台上Web API 是一个开源的、理想的、构建REST-ful 服务的技术
3、不像WCF REST Service.它可以使用HTTP的全部特点（比如URIs、request/response头，缓存，版本控制，多种内容格式）
4、它也支持MVC的特征，像路由、控制器、action、filter、模型绑定、控制反转（IOC）或依赖注入（DI），单元测试。这些可以使程序更简单、更健壮
5、它可以部署在应用程序和IIS上
6、这是一个轻量级的框架，并且对限制带宽的设备，比如智能手机等支持的很好
7、Response可以被Web API的MediaTypeFormatter转换成Json、XML 或者任何你想转换的格式。
WCF和WEB API我该选择哪个？
1、当你想创建一个支持消息、消息队列、双工通信的服务时，你应该选择WCF
2、当你想创建一个服务，可以用更快速的传输通道时，像TCP、Named Pipes或者甚至是UDP（在WCF4.5中）,在其他传输通道不可用的时候也可以支持HTTP。
3、当你想创建一个基于HTTP的面向资源的服务并且可以使用HTTP的全部特征时（比如URIs、request/response头，缓存，版本控制，多种内容格式），你应该选择Web API
4、当你想让你的服务用于浏览器、手机、iPhone和平板电脑时，你应该选择Web API
我们能得出两点结论。
一，如果你需要构建一个用于不同平台的服务，那么请使用WCF；
二，如果你需要构建基于因特网的服务，那么请使用Web API。