WCF服务编程——数据契约快速入门 - Charlie Jin

本邮件内容由第三方提供，如果您不想继续收到该邮件，可 点此退订 。

WCF服务编程――数据契约快速入门 - Charlie Jin  阅读原文»

WCF序列化流程

序列化

默认用户自定义类型（类和结构）并不支持序列化，因为.NET无法判断对象状态是否需要反射到流。 用户自定义类的实例支持序列化 需要添加[Serialazable]。若要允许可序列化类型包含非序列化的成员变量可使用[NonSerializad]

.Net格式器

BinaryFormatter 序列化为二进制格式
SoapFormatter 使用.NET 特定的SOAP XMl格式
两者格式器都实现IFormatter接口

两种格式器都要将类型的程序集及版本控制器信息持久化到流中，以保证序列化的对象能够被反序列化为正确的类型。

WCF格式器

使用[DataContract]进行标记类，使用[DataMember]标记成员
DataContractSerializer格式器继承XmlObjectSerializer。
在未曾标记DataContract特性，WCF就会自动推断，认为DataContract特性被应用到该类型上，且它的所有仅有成员（字段或属性）均被应用了DataMember特性。
组合数据契约：定义数据契约，对那些本身就是数据契约的成员也可以使用DataMember特性。-数据契约具有递归性质
数据契约事件 serializing发生成在序列化之前，serialized事件发生在序列化后，desrializing发生在反序列化之前，desreialized发生在反序列化之后

每个序列化事件处理方法都必须遵循如下的方法签名 void <Method Name>(StreamingContext context)

WCF在反序列化前必须创建一个对象，但是，WCF不会调用数据契约类的默认构造函数。

数据契约层级

WCF要求类层级的每一级数据契约都必须标记DataContract特性，该特性不可继承。WCF可以在类层级混合使用Serializable和DataContract特性
WCF不能接收子类型数据，只能使用[KnownType(typeof(subclass))] 或[ServiceKnownType(typeof(SubClass))]

配置文件方法

<add type="Contact,MyClassLibrary">
<knownType type="Customer,MyOtherClassLibrary"/>
</add>


使用配置文件主要解决的问题是：当添加一个新的子类时必须修改代码、重新编译和重新部署。

序列化顺序

在类型内部，默认的序列化顺序是按照字母的排序的，至于整个类层级的顺序，则是自上而下的。在序列化顺序不匹配的情况下，成员则以它们的值进行初始化。 自定义顺序可以使用[DataMember]的Order属性值进行调整，该属性的默认值为-1，也就是它默认WCF顺序

成员的Order属性设置了相同的值，WCF会按照成员的字母顺序排序

版本控制

• 新增成员;
  任何一端添加新的成员，然后将新的契约发送到旧的客户端或服务。在反序列化这样的数据契约类型时，DataContractSerializer会忽略新增成员。
• 缺失成员；
  客户端是针对旧的数据契约定义编写的，而与之交互的服务则是根据定义了新成员的契约定义编写的。当接收端的DataContractSerializer在消息中无法找到所需信息去反序列化的这些成员时，会根据成员的值进行反序列化。也就是说，将引用类型设置为null，将值类型设置为0。

• 双向传递，即新的数据契约与旧版本的数据契约之间相互传递，它同时需要向后与向前的兼容性。
  

  枚举

  枚举类型总是支持序列化的。不必应用DataContract特性，如果要将确定的枚举值排除于数据契约之外，就需要在枚举类型标记DataContract特性，并在枚举值明确标记为[EnumMember]特性，没有标记EnumMember毛发的枚举值不属于该枚举的数据契约。同时可以使用该特性的Value属性对枚举值设置别名。

  泛型

  不能定义包含了泛型类型参数的数据契约。便可以在数据契约中使用限定的泛型数据，只要在服务契约中指定了类型参数。
  数据契约被重命名的格式为：<原有名>Of<类型参数><散列值>
  同时也可以使用[DataContract(Name=”ClassNameOf{0}{1}”)]表示。标识符中的数字就是类型参数的序数，可以用｛#｝表示为散列值

  集合

  在使用集合接口IEnumberable,IList和ICollection,它他的传输型表示形式都使用了数组

  如果契约中的集合为具体集合类型，而且属于可序列化集合（标记为Serializable特性而不是DataContract特性），那么，只要提供的集合包含Add()方法,WCF就能够自动地将集合规范为数组类型。

  CollectionDataContract特性:该特性会检验Add()方法及检查IEumerable或IEnumerable接口是否存在。如果不存在，就会导致InvlidDataContractException异常。注：DataContract不能和CollectionDataContract一起使用

SQL Server 深入解析索引存储(下) - pursuer.chen  阅读原文»

标签：SQL SERVER/MSSQL SERVER/数据库/DBA/索引体系结构/非聚集索引

概述

非聚集索引与聚集索引具有相同的 B 树结构，它们之间的显著差别在于以下两点：

• 基础表的数据行不按非聚集键的顺序排序和存储。
  
  
• 非聚集索引的叶层是由索引页而不是由数据页组成。

既可以使用聚集索引来为表或视图定义非聚集索引，也可以根据堆来定义非聚集索引。非聚集索引中的每个索引行都包含非聚集键值和行定位符。此定位符指向聚集索引或堆中包含该键值的数据行。

非聚集索引行中的行定位器或是指向行的指针，或是行的聚集索引键，如下所述：

• 如果表是堆（意味着该表没有聚集索引），则行定位器是指向行的指针。该指针由文件标识符 (ID)、页码和页上的行数生成。整个指针称为行 ID (RID)。
  
  
• 如果表有聚集索引或索引视图上有聚集索引，则行定位器是行的聚集索引键。如果聚集索引不是唯一的索引，SQL Server 将添加在内部生成的值（称为唯一值）以使所有重复键唯一。此四字节的值对于用户不可见。仅当需要使聚集键唯一以用于非聚集索引中时，才添加该值。SQL Server 通过使用存储在非聚集索引的叶行内的聚集索引键搜索聚集索引来检索数据行。

对于索引使用的每个分区，非聚集索引在 index_id >0 的 sys.partitions 中都有对应的一行。默认情况下，一个非聚集索引有单个分区。如果一个非聚集索引有多个分区，则每个分区都有一个包含该特定分区的索引行的 B 树结构。例如，如果一个非聚集索引有四个分区，那么就有四个 B 树结构，每个分区中一个。

根据非聚集索引中数据类型的不同，每个非聚集索引结构会有一个或多个分配单元，在其中存储和管理特定分区的数据。每个非聚集索引至少有一个针对每个分区的 IN_ROW_DATA 分配单元（存储索引 B 树页）。如果非聚集索引包含大型对象 (LOB) 列，则还有一个针对每个分区的 LOB_DATA 分配单元。此外，如果非聚集索引包含的可变长度列超过 8,060 字节行大小限制，则还有一个针对每个分区的 ROW_OVERFLOW_DATA 分配单元。有关分配单元的详细信息，请参阅表组织和索引组织。B 树的页集合由 sys.system_internals_allocation_units 系统视图中的 root_page 指针定位。

要很好的理解这篇文章的内容之前需要先阅读我前面写的上中部分的两篇文章：

SQL Server 深入解析索引存储(中)

SQL Server 深入解析索引存储(上)

正文

非聚集索引结构

生成测试数据

CREATE TABLE Torder
(ID INT IDENTITY(1,1) NOT NULL,
NAME CHAR(100) NOT NULL,
pro VARCHAR(8000) NULL,
Statu INT NOT NULL,
IDATE DATETIME DEFAULT(GETDATE())
)
GO
---插入1000条测试数据
DECLARE @ID INT=1
WHILE(@ID<=1000)
BEGIN
INSERT INTO Torder(NAME,pro,Statu)VALUES('商品'+CONVERT(CHAR(20),@ID),REPLICATE(1,8000),LEFT(@ID,1))
SET @ID=@ID+1
END
GO
---创建非聚集索引
CREATE INDEX IX_Torder ON Torder
(NAME,Statu
)
INCLUDE(IDATE)


SELECT DISTINCT so.name, so.object_id,sp.index_id,internals.type_desc,internals.total_pages, internals.used_pages, internals.data_pages,first_iam_page, first_page, root_page
FROM sys.objects so
INNER JOIN sys.partitions sp ON so.object_id = sp.object_id
INNER JOIN sys.allocation_units sa ON sa.container_id = sp.hobt_id
INNER JOIN sys.system_internals_allocation_units internals ON internals.container_id = sa.container_id
WHERE so.object_id = object_id('Torder')

由于创建的表只有非聚集索引，所以整个表的页存储中有三部分数据：堆页面、溢出页面、索引页面；

堆中共有20个数据页和一个IAM页；

溢出单元有1001个页面包括一个IAM页；

索引中共有20个页其中18个数据页一个ROOT页和一个IAM页.

一个堆页对应多个溢出页，因为Pro有8000个字节所以一行占一页，而表的其它字段只有116个字节一个堆页可以存50条记录，所以并不是一个溢出页就唯一对应一个堆页

分析页的存储信息

---开启跟踪标志
DBCC TRACEON(3604,2588)
--DBCC TRACEOFF(3604,2588)
---获取对象的数据页，结构：数据库、对象、显示
DBCC IND(Ixdata,Torder,-1)

上一章中已经讲过了堆页面和溢出页面，所以现在就讲非聚集索引页

看过前面的文章应该一眼就能看出1281页是ROOT页，现在就分析1281页

分析非聚集索引根页