C#核心笔记——（五）框架概述

.NET Ftamework中几乎所有功能都是通过大量的托管类型提供的。这些类型组织在层次化的命名空间中，并打包为一套程序集，与CLR一起构成了.NET平台。

有些.NET类型是由CLR直接使用的，且对于托管宿主环境而言是必不可少的。这些类型位于一个名为mscorlib.dll的程序集中。包括C#内置类型、基本的集合类、流处理类型、序列化、反射、线程和原生互操作类型(“mscorlib"是“多语言标准通用对象运行行时库”，是Multi-language Standard Common Object Runtime Library的缩写”)。

在此之上是一些附加类型，它们充实了CLR层面的功能，提供了其他一些特性，如XML、网络和LINQ等。这些类型位于System.dll、System.Xml.dll和System.Core.dll中，并与mscorlib一起提供了丰富的编程环境供Framework的其他部分使用。

.NET Ftamework的其余部分是由一些实用API组成的。主要包含以下三个方面的功能：
1.用户界面技术
2.后台技术
3.分布式系统技术

表5-1 列出了各个版本的C#、CLR和.NET框架的兼容性历史。
C#、CLR和.NET Ftamework的版本

C#版本	CLR 版本	.NET Ftamework版本
1.0	1.0	1.0
1.2	1.1	1.1
2.0	2.0	2.0、3.0
3.0	2.0	3.5
4.0	4.0	4.0
5.0	4.5	4.5
6.0	4.6	4.6
7.0	4.6 / 4.7	4.6 / 4.7

.NET Ftamework 4.6的新特性
1.在GC类中加入了新的方法，这些方法为垃圾回收器对何时（不）进行垃圾回收提供了更多的控制。并在GC.Collect方法中添加了更多的调整选项，
2.全新的速度更快的64位JIT编译器
3.System.Numerics命名框架选择提供了支持硬件加速的矩阵、向量、大整数（BigInteger)和复数（Complex)类型。
4.提供了新的System.AppContext类。提供了统一的机制方便程序库的作者开启/关闭新API的功能。
5.Task将在创建时保存当前线程的文化和用户界面的文化信息。
6.更多的集合类型实现了IreadOnlyCollection< T >接口。
7.WPF提供了更多的改进，包括更好的接触支持和高分辨率（DPI)支持。
8.ASP.NET在Window10下开始支持HTTP/2和令牌绑定协议(Token Binding Protocol)。

.NET Framework的程序集和命名空间是相互交错的。其中最极端的就是mscorlib.dll和System.Core.dll了。虽然它们各自定义了很多命名空间但是没有一个命名空间是以mscorlib或者System.Core为前缀的。然而，有一些例子并没有这么明显，因此更容易混淆，如System.Security.Cryprography命名空间下的大部分类型是在System.dll中定义的。

许多核心类型都定义在mscorlib.dll、System.dll和System,Core.dll程序集中。其中mscorlib.dll程序集包含了运行时本身需要的类型；System.dll和System.Core.dll包含了程序员需要的其他核心类型。后两个程序集单独分开是历史原因造成的：当Microsoft退出.NET Framwork3.5时采用增量的开发方式，以便能够让它作为一层运行在现有CLR2.0上。因此几乎所有新添加的核心类型都进入了一个新的程序集，Microsoft将其命名为System.Core.dll。

.NET Ftamework 4.7的新特性
.NET Ftamework 4.7 是一个主要作为维护性质，而非添加新功能版本。它修正了很多缺陷，并进行小幅的改进，包括：
1.将System.ValueTuple结构体纳入进了Framework 4.7体系。因此在C# 7 中不必引用System.ValueTuple.dll程序集就可以使用元组了。
2.改进了WPF的支持。
3.改进了Windows Forms对高分辨率显示器的支持。

5.1 .NET标准2.0

在第1章时介绍了三种替代.NET Framework的跨平台开发手段：
1.应用于window10设备/桌面的UWP
2.支持windows、Linux和MacOS的.NET Core/ASP.NET Core
3.用于移动设备开发的Xamarin（支持iOS、Android和Windows 10设备）。
可喜的是到.NET Core2.0时，这些框架（包含.NET Framework 4.6.1及之后的版本）将其核心功能进行了提炼，形成了一套拥有相似类型和成员的基础类型库。这些共同的部分形成了一套标准，称为NET标准2.0（.NET Standard 2.0)。

因此，若使用Visual Studio 2017开发程序库，则可以将目标框架设置为.NET标准2.0而不是选择特定的框架。这样，你的程序库就具备了可移植性，可以不需要修改就运行在上述四种框架的最近版本上。
.NET标准不是一套框架；它仅仅是一个描述（类型和成员的）最小功能集基线的规范，以保证特定框架间的兼容性。这个概念和C#的接口很相似：.NET标准类似一个接口，而框架是实现接口的具体类型。

5.1.1 旧版本的.NET标准

除了.NET标准2.0外，还有一些现存的旧版本的.NET标准，主要是:1.1、1.2、1.3和1.6。更高的版本号意味着对低版本号的扩展。例如，如果一个程序库的目标标准为1.6，那么该程序库不仅可以兼容前面提到的四个版本的最近版本，还可以兼容.NETCore 1.0。而如果该程序库支持.Net标准1.3,那么它可以支持包括.NET Framework4.6.0在内的所有框架。

2.0标准相比1.x标准增添了几千个API。因此从2.0转1.x，支持1.x的标准是非常困难的。如果你需要支持更老的框架，但是不需要跨平台的兼容性，那么更推荐将程序库的目标框架设置为特定版本的框架。

5.1.2 引用程序集

为了编译程序，必须将程序中使用的程序集（程序集中包含了应用程序需要的那一部分框架功能）引用进来。例如使用了LINQ-to-XML查询的简单的.NET Framework控制台应用程序需要引用mscorb.dll、System.dll、System.Xml.dll、System.Xml.Linq.dll以及System.Core.dll。

在Visual Studio中，可以在项目中添加引用来引用程序集。引用程序集仅仅是编译器的需要，运行时的程序集并不要求和编译时引用的程序集保持一致。因此，在编译时，可以使用一种特殊的，只包含外壳而不包含任何编译代码的引用程序集。而这正是.NET标准的工作原理：我们引用的程序集称为netstandard.dll，它包含了所有.NET标准2.0中的类型和成员，当并不包含实际编译的代码。后续则通过程序集重定向特性，在运行时加载“真正的”程序集。

在引用程序集时，也可以将目标框架版本设定为比机器上安装的框架版本低的版本。例如，在安装了Visual Studio2017和.NET Framework4.7的系统上我们仍然可以将项目的版本设定为.NET FrameWork 4.0。

5.2 CLR和核心架构

5.2.1 系统类型

大多数基础类型都位于System命名空间。其中包括C#的内置类型，Exception基类、Enum、Array、Delegate基类，以及Nullable、Type、DateTime、TimeSpan和Guid。System命名空间还包含执行数学计算功能的Math类、生成随机数字的Random类和用于在不同类型执行转换操作的类型（Convert和BitConverter）。
除此之外.NET Framework中用来执行各种任务的标准协议的接口，例如用于格式化任务的IFormattable接口和用于顺序比较的IComparable接口。

System命名空间还定义了IDisposable接口以及与垃圾回收器交互的GC类。

5.2.2 文本处理

System.Text命名空间中的StringBuilder类（可编辑或可变的字符串类型）和用于文本编码的类型，例如UTF-8的Encoding类及其子类型。
System.RegularExpressions命名空间中基于模式进行搜索和替换操作的高级类型。

5.2.3 集合

.NET Framework提供的各种处理集合项目的类型。包括基于列表和基于字典的结构，以及一组统一其常用特性的标准接口。这些集合类型都定义在如下的命名空间中：

using System.Collections;
using System.Collections.Generic;
using System.Collections.Specialized;
using System.Collections.ObjectModel;
using System.Collections.Concurrent;

5.2.4 查询

LINQ是在.NET Framework3.5版本中添加的功能。它允许对本地和远程集合（例如 SQL Server的表）执行类型安全的查询。LINQ的巨大优势是提供了一种跨多个领域的统一查询AP。进行LINQ查询的类型是.NET2.0的组成部分，位于以下的命名空间中:

using System.Linq;
using System.Linq.Expressions;
using System.Xml.Linq;

完整的.NET Framework还包含以下命名空间：

System.Data.Linq
System.Data.Entity

5.2.5 XML

XML在.NET Framework中使用广泛。,NET Framework对XML有良好的支持。LINQ to XML，一个可以通过LINQ构建和查询的轻量XML文档对象模型。旧版本的W3C DOM模型，以及提高性能的底层读/写类。同时还包含Framework对XML大纲（Schema）、样式表（Stylesheet）和XPath的支持，这些XML相关内容包含在如下的命名空间中：

using System.Xml;
using System.Xml.Linq;
using System.Xml.Schema;
using System.Xml.Serialization;
using System.Xml.XPath;
using System.Xml.Xsl;

5.2.6 诊断

.NET的日志和断言。如何与其他进程交互，编写windows事件日志以及使用性能计数器进行监控。这些类型是在System.Diagnostics命名空间定义的。需要注意的是Windows相关的功能并非.NET标准的一部分，因此仅仅在.NET Framework中有效。

5.2.7 并发与异步

大多数现代应用都需要同时处理多个任务。从C#5开始，通过引入异步函数和诸如任务、任务组合器等高级结构大大简化了相关操作。后续介绍多线程基础概念详解。执行线程和异步操作的类型位于System.Treading和System.Treading.Task命名空间下。

5.2.8 流与I/O

Framework提供了基于流的模型进行底层输入输出操作。流一般用于直接从文件或网络连接中进行读写操作。流可以串联，或包裹在装饰器流中以实现压缩或加密功能。后续详解.NET的流架构，及其对文件与目录、压缩、隔离存储、管道和内存映射文件的特殊支持。.NET中的Stream和I/O相关的类型定义在System.IO命名空间下；而WinRT中进行文件I/O的类型则定义在windows.Storage中。

5.2.9 网络

System.Net命名空间下的类型可以直接访问标准的网络协议，如HTTP、FTP、TCP/IP和SMTP。后续详解这些协议通信。首先我们从一些简单任务开始，例如下载一个页面；最后将介绍如何用TCP/IP直接接收POP3的电子邮件。以下是相应内容的命名空间：

using System.Net;
using System.Net.Http;
using System.Net.Mail;
using System.Net.Sockets;

最后两个命名空间对于Windows8/8.1(WinRT）的Windons商店的应用程序是不适用的。但是对于Windows10商店应用程序是有效的，这是因为UWP是.NET标准2.0契约的一部分。WinRT应用程序可以考虑使用第三方库进行邮件发送，并使用Windows.NETworking.Sockets命名空间下的类型进行套接字的编程。

5.2.10 序列化

Framework提供了机制系统来将对象保存成二进制及文本格式，或从这些格式的数据中恢复对象。这些系统是分布式应用程序技术（如WCF、Web服务和Remoting)所必须的。除此以外，还可以将对象保存成文件或从文件中恢复对象。后续介绍三种主要的序列化引擎：数据契约序列化器、二进制序列化器以及XML序列化器。（.NET Framework中还有JSON序列化器）。这些用于序列化的类型位于以下的命名空间中：

using System.Runtime.Serialization;
using System.Xml.Serialization;

5.2.11 程序集、反射和特性

C#程序编译后产生的程序集包含可执行指令（存储为中间语言或者称为IL)和元数据（描述了程序的类型、成员和特性）。通过反射机制可以在运行时检查元数据或者执行某些操作，如动态调用方法。通过Reflection.Emit可以随时创建新代码。

程序集的构成，以及如何为程序集签名。全局程序缓存（Golbal Assembly Cache,GAC)、资源、以及文本引用解析的方式。

反射和特性。包括检查元数据、动态调用函数、编写自定义的特性，创建新类型以及解析原始的IL。使用反射和程序集的类型主要集中在以下命名空间中：

using System;
using System.Reflection;
using System.Reflection.Emit;

5.2.12 动态编程

动态语言运行时（Dynamic Language Runtime,DLR)。DLR从.NET Framework4.0开始就是CLR的一部分了。实现访问者模式、书写自定义的动态对象，并实现和IronPython的互操作。动态编程的类型位于System.Dynamic中。

5.2.13 安全性

,NET Framework 具有自己的安全层，从而能够将程序集放入沙箱，甚至将自己装入沙箱。代码访问、角色和身份安全以及CLR4.0的透明模型。及Framework中的密码学部分、包括加密、散列和数据保护。

using System.Security;
using System.Security.Permissions;
using System.Security.Policy;
using System.Security.Cryptography;

5.2.14 高级线程功能

C#的异步函数减少了对底层的技术依赖，显著简化了并发编程。然而，开发者有时侯仍然需要使用信号发送结构、线程本地部署、读写锁等功能，线程类型位于System.Threading命名空间。

5.2.15 并行编程

多核处理器应用相关的库和类型。其中包括任务并行API、命令式数据并行和函数式并行（PLINQ)机制。

5.2.16 应用程序域

CLR支持在一个进程内增加额外的隔离级别，称为应用程序域。应用程序域的属性。并展示同一个进程内创建和使用额外的应用程序域来执行其他操作，如单元测试。Remoting和应用程序域进行通信。

虽然可以使用System命名空间中的AppDomain类来获得当前的应用程序域，但创建独立的应用程序域并不是.NET标准2.0的一部分。

5.2.17 原生互操作性与COM互操作性

.NET可以与原生代码和COM代码实现互操作。原生互操作性可以调用非托管DLL中的函数、注册回调函数、映射数据结构并操作原生数据类型。COM互操作性可以允许调用COM类型，将.NET的类型传递给COM。支持这种功能的类型位于System.Runtime.InteropServices命名空间中。

5.3应用技术

5.3.1 用户界面API

基于用户界面的应用程序可以划分为两类：瘦客户端，例如网站；富客户端，即用户必须下载并安装到电脑或移动设备上的程序。
对于瘦客户端，.NET提供了ASP.NET和ASP.NET.Core
对于面向Windows 7/8/10桌面的富客户端，.NET提供了WPF和Windows Forms API。而对于面向iOS、Android和Windows 10桌面和设备的富客户端应用程序，则由Xamarin提供支持。此外，面向Windows10桌面和设备的富客户端商店应用由UWP提供支持。

5.3.1.1 ASP.NET

使用ASP.NET编写的应用程序托管与windows的IIS上，并可以从几乎所有的Web浏览器上访问。ASP.NET相对于客户端技术有如下的优点：
1.客户端不需要任何部署
2.客户端可以运行在非windows平台上
3.部署更新容易

ASP.NET应用程序的大部分功能都运行在服务器上，因此可以将数据访问层设计在同一个应用程序域中而不损害应用程序的安全性和可伸缩性。相反，富客户端往往不具备相应的安全性和可伸缩性（富客户端的方法是在客户端和数据库之间插入一个中间层，中间层在远程应用程序服务器上运行（往往和数据库服务器一起），并通过WCF、Web服务或Remoting与富客户端进行通信）。

在编写Web页面时，可以选择传统的Web Forms或者新的MvC（Model-View-Controller)API。它们构建在ASP.NET基础设施上。.NET Framework从一开始就支持Web Forms,而MvC则是在Ruby on Rails和MonoRail流行之后才出现的。总体上，它提供了比Web Forms更好的编程抽象，同时对生成HTML提供了更多控制。唯一缺失的是Web Forms的设计器。拥有设计器这一特点是Web Forms仍然适合编写静态内容为主的页面。

ASP.NET的缺点和大部分瘦客户端的常见缺点相同：
1.虽然Web浏览器通过HTML5可以提供丰富绚丽的界面以及AJAX调用能力，它相比原生的富客户端API(如WPF)在功能和性能上仍然有较大的差距。
2.维持客户端的状态（或替代客户端）还是非常艰难的。

编写ASP.NET应用程序的类型位于System,Web.dll程序集的System.Web.UI命令空间及其子命名空间中。而ASP.NET5则可以从CuGet上获得。

5.3.1.2 ASP.NET Core

ASP.NET Core是最近新增的框架。它和ASP.NET相似，但是可以同时运行在.NET Framework和.NET Core上（支持跨平台部署）。ASP.NET Core 使用了轻量级的模块化架构，可以自托管在指定的进程中，并且拥有开源许可证。和其前辈不同，它并不依赖System.Web也没有Web Forms的历史负担。尤其适合开发为服务并将其部署在容器中。

5.3.1.3 Window Presentation Foundation(WPF)

WPF是在.NET Framework3.0时引入的，用于编写富客户端应用程序。WPF相比之前的Windows Forms的优点在于：
1.支持复杂图形，如任意的变换、3D渲染、多媒体、真实透明。还可以使用样式和模板支持皮肤更换功能。
2.主要度量单位不是像素、因此应用程序开源正确显示在任何DPI（每英寸的点数）设备上。
3.支持大量的动态布局特性，因此开源随意设置应用程序布局而不用担心出现元素重叠。
使用DirectX实现快速渲染，支持显卡硬件加速。
提供了可靠的数据绑定支持，
可以使用XAML对用户界面进行声明式描述，并和后台的“code-behind"文件分开维护。有助于显示和功能的隔离。
然而，WPF的规模和复杂度导致它的学习周期较长。
编写WPF应用程序的类型位于System.Windows命名空间以及处了System.Windows.Form之外的所有子命名空间中。

5.3.1.4 Windows Forms

windows Forms是和.NET Framework同时出现的富客户端API。和WPF相比，Windows Forms相对简单。它支持编写一般Windows应用程序所需的大部分特性，而且能够良好的兼容遗留应用程序。但是和WPF相比，他有很多缺点：
1.它的位置和尺寸是基于像素的，当客户端的DPI和开发者的设置不同时，用它编写的应用程序很容易出错（.NET Framework 4.7在这个方面进行了一些改进）。
2.绘制非标准控件的API基于GDI+，虽然它相对灵活，但是渲染大的区域时速度比较缓慢（在缺少双缓冲的情况下会出现画面抖动）。
3.控件缺少真实透明支持。
4.大部分控件是不可组合的。例如，你无法将一个图片控件放在一个选项卡控件的标题上。而自定义列表视图和下拉列表就更加耗时耗力了。
5.难以进行恰当的动态布局。
最后一条是使用WPF代替Windows Forms的绝佳理由，即使编写的业务应用程序所需要的仅仅是一个用户界面而不需要考虑”用户体验“。WPF中的布局元素，例如Grid，可以方便把标签和文本对齐，即使将文本进行本地化之后也总是对齐的，并不需要添加额外的处理逻辑，同时还不会出现画面抖动的情况。此外，你不需要处理和屏幕分辨率相关的底层逻辑，WPF的布局元素从设计之初就将适应性的尺寸调整参考在内了。从积极的方面看，Windows Form学习过程相对简单，并且有丰富的第三方控件的支持。Windows Form相关的类型位于System.Windows.Form.dll程序集下的System.Windows.Forms命名空间，以及System.Drawing.dll程序集下的System.Drawing命名空间中。后者还包括绘制自定义控件所需的GDI+的类型。

5.3.1.5 Xamarin

Xamarin现在已经归属Microsoft。它可以使用C#编写面向iOS、Android和Windows Phone的移动应用程序。它是跨平台的，因此它并非在.NET FrameWork上运行，而是运行在自己的框架上（该框架开源基于Mono框架）。

5.3.1.6 UWP

UWP（Universal Windowns Platform)用于为Windows 10 桌面和设备编写应用程序，这种应用程序通过windows商店分发。它的富客户端API专门为编写触控优先的用户界面设计，并借鉴了WPF的设计灵感，使用XAML进行布局。其命名空间是：Windows.UI和Windows.UI.Xaml。

5.3.1.7 Silverlight

Silverlight并不属于.NET Framework，它用于开发类似Macromedia Flash那样的在Web浏览器上运行的图形界面。HTML5兴起之后，Microsoft就放弃了Silverlight。

5.3.2 后台技术

5.3.2.1 ADO.NET

ADO.NET是托管数据访问API。虽然它的名称源于20世纪90年代的ADO(ActiveXDataObject)，但是这两种技术是完全不同的。ADO.NET包含了两个主要的底层组件：
1.提供者层：提供者模型定义了对数据库提供者进行底层访问的通用类和接口。这些接口包括连接、命令、适配器和读取器（前向的、只读的数据库游标）。Framework包含了对Microsoft SQL Server的原生支持。对于其他的数据库则由第三方提供驱动支持。
2.DataSet模型：DataSet是数据的结构化缓存。它类似于一个基础的内存数据库，其中定义了诸如表，记录行、列、关系、约束、视图等SQL结构。通过对数据缓存的编程，可以减少服务器的交互数量，增加服务器间的可伸缩性，改善富客户端用户界面的响应性。DataSet是可序列化的，它可以通过客户端和服务器应用程序之间的线路进行传输。

在提供者层之上，有三种API提供了通过LINQ查询数据库的功能：
1.Entity Framework(仅用于.NET Framework)
2.Entity Framework Core(仅用于.NET Framework和.NET Core)
3.LINQ to SQL(仅用于.NET Framework)

这三种技术都包含了对象/关系映射器（object relational mappers,ORM)。这意味着它们会自动将对象（基于用户定义的类）映射到数据库的记录行。这允许用户通过LINQ对数据进行查询，而不是编写SQL SELECT语句，或更新,而不是越过书写DELETE、UPDATA语句。因此它显著减少了应用程序数据访问层的代码（特别是那些曲折往复的代码），提供了强的静态类型安全性，并且这些技术不再需要一定使用DataSet作为数据的容器了（当然，多层应用程序中，使用DataSet对状态变化进行存储和序列化仍然是非常有效的）。在书写多层程序时，可以将Entity Framework或LINQ to SQL和DataSet结合使用。换句话说，Microsoft提供的ORM还不能作为书写多层应用程序的一站式解决方案。

LINQ to SQL比 Entity Framework更简单，并且曾经一度能够生成更好的SQL。Entity Framework则可以更灵活地在数据库和查询的类之间创建复杂的映射，并提供了通用模型以支持SQL Server之外的第三方数据库。

Entity Framework Core则使用更简单的设计，参考LINQ to SQL重新实现了Entity Framework。它放弃了复杂的Entity数据模型并可以同时运行在.NET Framework和.NET Core上。

.NET标准2.0包含了提供者层的公共接口以及DataSet。但舍弃了SQL Server特有的类型和对象/关系映射器。

5.3.2.2 windows工作流（仅支持.NET Framework）

Windows工作流是一个对可能长期运行的业务过程进行建模和管理的框架。它的目标是成为能提供一致性和互操作性的标准运行时库。工作流还可以降低动态控制决策树的编码量。

Windows工作流严格意义上并非一种后台技术，你可以在任何地方使用它（例如，UI的页面流中）。

Windows工作流是从.NET Framework3.0快速出现的，它的类型定义在System.WorkFlow命名空间中。工作流在.NET Framework4.0是进行了可观的修改，新增加的类型位于System.Activities命名空间中。

5.3.3 分布式系统技术

5.3.3.1 Windows Communication Foundation（WCF)

WCF是.NET Framework3.0中引入的一个复杂的通信基础框架。WCF非常灵活且可以可进配置。它几乎可以完全替代其前任框架：Remoting和（.ASMX)Web服务了。
WCF、Remoting和Web服务的相似之处在于它们都实现了客户端和服务器通信的基本模型：
1.在服务端，可以指定远程客户端应用程序能够调用的方法。
2.在客户端，可以指定或推断将要调用的服务器方法的签名。
3.在服务器和客户端，都可以选择一种传输协议和通信协议（在WFC中，这是通过使用绑定实现的）。
4.客户端和服务器建立连接。
5.客户端调用远程方法，并在服务器上透明地执行。

WCF会通过服务契约和数据契约进一步对客户端和服务器进行解耦。概念上，客户端会发送一条（XML或者二进制）消息给远程服务的终端，而非直接调用一个远程方法。这种解耦方式的好处是，客户端不会依赖于.NET平台或其他的私有通信协议。

WCF是高度可配置的，并对标准化的基于SOAP(简单对象访问协议，Simple Object Access Protocol）的消息协议提供了广泛的支持。包括WS-*安全扩展。这样，应用程序不但可以和其他运行着不同软件（可能是不同平台）的组织进行通信，同时还支持一些诸如加密的高级特性。但在实践中，这些协议的复杂性阻碍了其他平台的接纳程度，现在最流行的基于消息的互操作机制则是基于HTTP的REST通信。Microsoft通过ASP.NET的WebAPI层对这种方式提供了支持。

对于.NET到.NET通信，WCF提供了比REST API更加丰富的序列化选项和工具。WCF并没有限制在HTTP协议上，可以进行二进制序列化，因此它更具潜在的性能优势。

于WCF通信相关的类型位于System.Service.Model及其子命名空间中。

5.3.3.2 WebAPI

Web API运行于ASP.NET/ASP.NET Core之上，在架构上和Micorsoft的MVC API相似，只不过Web API不是为生成Web页面，而是为提高服务和数据进行设计的。相比WCF，它采用了流行且更易用的基于HTTP的REST约定，使用简单的方式于最广泛的平台进行交互。

REST的内部实现比WCF依赖的SOAP和WS-协议简单。它构建于事实标准上且充分利用HTTP协议提供的能力，RESR协议从架构上也能够更优雅地完成系统间的解耦。

5.3.3.3 Remoting 和 Web服务（仅支持.NET Framework)

Remoting和.ASMX Web服务是WCF的前驱。目前，Remoting几乎已经完全被WCF替代，而.ASMX Web服务亦已经完全被替代。

Remoting目前仍然用于同一个进程的不同应用程序域之间的通信。Remoting面向的是紧耦合的应用程序。其典型的应用场景是客户端和服务器都是.NET应用程序，并且由一家公司编写（或者它们共享公共的程序集）。它们之间的通信一般都涉及潜在复杂的自定义.NET对象的交换，而Remoting基础设施可以在不进行干预的情况下自动完成序列化和反序列化。

Remoting相关的类型位于System.Runtime.Remoting命名空间内；Web服务相关的类型位于System.Web.Services命名空间内。