Serialization 및 Deserialization

루트 형식은 serialize 또는 deserialize되는 인스턴스의 형식입니다. DataContractSerializer 에는 여러 개의 생성자 오버로드가 있지만, 최소한 type 매개 변수를 사용하여 루트 형식을 지정해야 합니다.

특정 루트 형식에 대해 만들어진 serializer는 해당 형식이 루트 형식에서 파생된 경우가 아니라면 다른 형식을 serialize하거나 deserialize하는 데 사용할 수 없습니다. 다음 예제에서는 두 개의 클래스가 나옵니다.

[DataContract]
public class Person
{
    // Code not shown.
}

[DataContract]
public class PurchaseOrder
{
    // Code not shown.
}

이 코드에서는 Person 클래스의 인스턴스를 serialize하거나 deserialize하는 데에만 사용할 수 있는 DataContractSerializer의 인스턴스를 구성합니다.

DataContractSerializer dcs = new DataContractSerializer(typeof(Person));
//This can now be used to serialize/deserialize Person but not PurchaseOrder.

Serialize되는 형식 중 KnownTypeAttribute 특성이나 일부 다른 메커니즘을 사용하여 아직 처리되지 않은 형식에 다형성이 포함되는 경우, 알려진 가능한 형식 목록을 knownTypes매개 변수를 사용하여 serializer의 생성자에게 전달해야 합니다. 알려진 형식에 대한 자세한 내용은데이터 계약 알려진 형식을 참조하십시오.

다음 예제에서는 특정 형식의 컬렉션인 LibraryItem이 포함된 클래스 LibraryPatron을 보여 줍니다. 두 번째 클래스는 LibraryItem 형식을 정의합니다. 세 번째와 네 번째 클래스인 Book 및 Newspaper는 LibraryItem 클래스에서 상속됩니다.

<DataContract()>  _
Public Class LibraryPatron
    <DataMember()> _
    Public borrowedItems() As LibraryItem
End Class 

<DataContract()>  _
Public Class LibraryItem
   'code not shown
End Class 'LibraryItem

<DataContract()>  _
Public Class Book
    Inherits LibraryItem
    'code not shown
End Class 

<DataContract()>  _
Public Class Newspaper
    Inherits LibraryItem
    'code not shown
End Class 

다음 코드에서는 knownTypes 매개 변수를 사용하여 serializer의 인스턴스를 구성합니다.

//Create a serializer for the inherited types using the knownType parameter.
Type[] knownTypes = new Type[] { typeof(Book), typeof(Newspaper) };
DataContractSerializer dcs =
new DataContractSerializer(typeof(LibraryPatron), knownTypes);
// All types are known after construction.

일반적으로 개체가 serialize되면 데이터 계약 이름과 네임스페이스에 따라 가장 바깥쪽 XML 요소의 기본 이름과 네임스페이스가 결정됩니다. 모든 내부 요소의 이름은 데이터 멤버 이름을 따르며 해당 네임스페이스는 데이터 계약의 네임스페이스와 동일합니다. 다음 예제에서는 DataContractAttribute 및 DataMemberAttribute 클래스의 생성자에 Name 및 Namespace 값을 설정합니다.

[DataContract(Name = "PersonContract", Namespace = "http://schemas.contoso.com")]
public class Person2
{
    [DataMember(Name = "AddressMember")]
    public Address theAddress;
}

[DataContract(Name = "AddressContract", Namespace = "http://schemas.contoso.com")]
public class Address
{
    [DataMember(Name = "StreetMember")]
    public string street;
}

Person 클래스의 인스턴스를 serialize하면 다음과 유사한 XML이 생성됩니다.

<PersonContract xmlns="http://schemas.contoso.com">
  <AddressMember>
    <StreetMember>123 Main Street</StreetMember>
   </AddressMember>
</PersonContract>

그러나 rootName 및 rootNamespace 매개 변수의 값을 DataContractSerializer 생성자에 전달하여 루트 요소의 기본 이름과 네임스페이스를 사용자 지정할 수 있습니다. rootNamespace는 데이터 멤버에 해당하는 포함된 요소의 네임스페이스에 영향을 주지 않고,가장 바깥쪽 요소의 네임스페이스에만 영향을 줍니다.

이러한 값은 XmlDictionaryString 클래스의 인스턴스나 문자열로 전달하여, 이진 XML 형식을 통해 최적화할 수 있습니다.

일부 DataContractSerializer 생성자 오버로드에는 maxItemsInObjectGraph 매개 변수가 있습니다. 이 매개 변수는 serializer가 단일 ReadObject 메서드 호출에서 serialize하거나 deserialize하는 최대 개체 수를 결정합니다. 이 메서드는 항상 하나의 루트 개체를 읽지만 이 개체의 데이터 멤버에 다른 개체가 있을 수 있으며, 마찬가지로 그러한 개체에도 다른 개체가 있을 수 있습니다. 기본값은 65536입니다. 배열을 serialize하거나 deserialize할 때 모든 배열 항목은 개별 개체로 계산됩니다. 또한 일부 개체에는 큰 메모리 표현이 있을 수 있으므로 서비스 거부 공격을 방지하기에 이 할당량만으로 충분하지 않을 수 있습니다. 자세한 내용은 다음을 참조하십시오.데이터에 대한 보안 고려 사항. 이 할당량을 기본값보다 크게 늘려야 할 경우 데이터를 읽고 쓸 때 보내는 측(serialize)과 받는 측(deserialize)에 모두 적용되므로 양측에서 값을 늘려야 합니다.

라운드트립은 개체가 한 번에 deserialize 및 다시 serialize될 때 발생합니다. 예를 들면 XML에서 개체 인스턴스로 이동하고 다시 XML 스트림으로 이동합니다.

일부 DataContractSerializer 생성자 오버로드에는 기본적으로 false로 설정된 ignoreExtensionDataObject 매개 변수가 있습니다. 이 기본 모드에서는 데이터 계약에서 IExtensibleDataObject 인터페이스를 구현하는 한, 라운드트립 시 이전 버전을 통해 최신 버전의 데이터 계약에서 다시 이 최신 버전으로 데이터 손실 없이 데이터를 보낼 수 있습니다. 예를 들어 Person 데이터 계약의 버전 1에 Name 및 PhoneNumber 데이터 멤버가 들어 있고 버전 2에서 Nickname 멤버를 추가한다고 가정합니다. IExtensibleDataObject 가 구현되면 버전 2에서 버전 1로 정보를 보낼 때 Nickname 데이터가 저장된 다음 다시 serialize될 때 다시 내보내집니다. 따라서 라운드트립 시 데이터가 손실되지 않습니다. 자세한 내용은 다음을 참조하십시오.이후 버전과 호환되는 데이터 계약 및 데이터 계약 버전 관리.

라운드트립과 관련된 보안 및 스키마 유효성 검사 문제

라운드트립 사용 및 사용 안 함

다음 코드에서처럼 serializer는 일반적으로 개체 ID를 고려하지 않습니다.

[DataContract]
public class PurchaseOrder
{
    [DataMember]
    public Address billTo;
    [DataMember]
    public Address shipTo;
}

[DataContract]
public class Address
{
    [DataMember]
    public string street;
}

다음 코드에서는 구매 주문서를 만듭니다.

//Construct a purchase order:
Address adr = new Address();
adr.street = "123 Main St.";
PurchaseOrder po = new PurchaseOrder();
po.billTo = adr;
po.shipTo = adr;

billTo 및 shipTo 필드는 동일한 개체 인스턴스에 설정됩니다. 그러나 생성된 XML은 복제된 정보를 복제하는데, 다음과 유사한 XML이 생성됩니다.

<PurchaseOrder>
  <billTo><street>123 Main St.</street></billTo>
  <shipTo><street>123 Main St.</street></shipTo>
</PurchaseOrder>

그러나 이 방법은 다음과 같이 바람직하지 않은 특성을 갖습니다.

• 성능.데이터 복제가 비효율적입니다.

• 순환 참조.개체가 다른 개체를 통해 자신을 참조하는 경우에도, 복제로 serialize하면 무한 루프가 발생합니다.이 경우 serializer가 SerializationException을 throw합니다.

• 의미.경우에 따라 두 개의 참조가 똑같은 두 개의 개체로 이루어지는 것이 아니라, 하나의 동일한 개체로 이루어지도록 하는 것이 중요합니다.

이러한 이유로 인해, 일부 DataContractSerializer 생성자 오버로드에는 기본값이 false인 preserveObjectReferences 매개 변수가 있습니다.이 매개 변수를 true로 설정하면, WCF에서만 인식하는 개체 참조를 인코딩하는 특수한 방법이 사용됩니다. true 로 설정된 경우 XML 코드 예제는 이제 다음과 유사합니다.

<PurchaseOrder ser:id="1">
  <billTo ser:id="2"><street ser:id="3">123 Main St.</street></billTo>
  <shipTo ser:ref="2"/>
</PurchaseOrder>

"ser" 네임스페이스는 표준 serialization 네임스페이스(http://schemas.microsoft.com/2003/10/Serialization/)를 참조합니다.각 데이터 부분은 단 한 번만 serialize되고 이 데이터에 ID 번호가 제공됩니다. 이후 사용에서는 이미 serialize된 데이터를 참조하게 됩니다.

중요
데이터 계약 XMLElement에 "id" 및 "ref" 특성이 모두 있으면 "ref" 특성이 적용되는 "id" 특성은 무시됩니다.

이 모드의 제한 사항을 파악하는 것도 중요합니다.

• preserveObjectReferences가 true로 설정된 상태에서, DataContractSerializer에서 생성한 XML은 다른 기술과 상호 운용할 수 없고, 또한 preserveObjectReferences가 true로 설정된 상태에서는 다른 DataContractSerializer 인스턴스에서만 이 XML에 액세스할 수 있습니다.

• 이 기능에 대해서는 메타데이터(스키마)가 지원되지 않습니다.생성된 스키마는 preserveObjectReferences가 false로 설정된 경우에만 유효합니다.

• 이 기능으로 인해 serialization 및 deserialization 프로세스 실행 속도가 느려질 수 있습니다.데이터를 복제하지 않아도 되지만 이 모드에서 추가 개체 비교를 수행해야 합니다.

주의
preserveObjectReferences 모드를 사용하는 경우, maxItemsInObjectGraph 값을 올바른 할당량으로 설정하는 것이 특히 중요합니다.이 모드에서 배열이 처리되는 방식 때문에, 공격자가 maxItemsInObjectGraph 할당량에 의해서만 제한되는 과다한 메모리 소비를 일으키는 작은 악의적인 메시지를 쉽게 작성할 수 있습니다.

일부 DataContractSerializer 생성자 오버로드에는 null로 설정될 수 있는 dataContractSurrogate 매개 변수가 있습니다. 그렇지 않으면 이 오버로드를 사용하여 IDataContractSurrogate 인터페이스를 구현하는 형식인 데이터 계약 서로게이트를 지정할 수 있습니다. 그러면 인터페이스를 사용하여 serialization 및 deserialization 프로세스를 사용자 지정할 수 있습니다. 자세한 내용은 다음을 참조하십시오.데이터 계약 서로게이트.

개체를 serialize하는 가장 기본적인 방법은 개체를 WriteObject 메서드에 전달하는 것입니다. 그리고 세 개의 오버로드가 있는데, 각각 Stream, XmlWriter 또는 XmlDictionaryWriter에 쓰기 위한 오버로드입니다. Stream 오버로드를 사용하면 UTF-8 인코딩 형식의 XML로 출력됩니다. XmlDictionaryWriter 오버로드를 사용하면 serializer는 이진 XML에 대한 출력을 최적화합니다.

WriteObject 메서드를 사용할 때, serializer는 래퍼 요소에 기본 이름 및 네임스페이스를 사용하고, 콘텐츠와 함께 래퍼 요소를 작성합니다. 이전 단원인 "기본 루트 이름 및 네임스페이스 지정"을 참조하십시오.

다음 예제에서는 XmlDictionaryWriter를 사용하여 작성하는 방법에 대해 설명합니다.

Person p = new Person();
DataContractSerializer dcs =
    new DataContractSerializer(typeof(Person));
XmlDictionaryWriter xdw =
    XmlDictionaryWriter.CreateTextWriter(someStream,Encoding.UTF8 );
dcs.WriteObject(xdw, p);

이렇게 하면 다음과 유사한 XML이 생성됩니다.

<Person>
  <Name>Jay Hamlin</Name>
  <Address>123 Main St.</Address>
</Person>

각각 끝 요소를 작성하고 개체 내용을 작성하며 래퍼 요소를 닫으려면, WriteStartObject, WriteObjectContent 및 WriteEndObject 메서드를 사용합니다.

참고
이러한 메서드의 Stream 오버로드가 없습니다.

이러한 단계별 serialization을 사용하는 방법은 일반적으로 두 가지가 있습니다. 한 가지 방법은 다음 예제와 같이, 특성 또는 설명 등의 내용을 WriteStartObject와WriteObjectContent 사이에 삽입하는 방법입니다.

dcs.WriteStartObject(xdw, p);
xdw.WriteAttributeString("serializedBy", "myCode");
dcs.WriteObjectContent(xdw, p);
dcs.WriteEndObject(xdw);

이렇게 하면 다음과 유사한 XML이 생성됩니다.

<Person serializedBy="myCode">
  <Name>Jay Hamlin</Name>
  <Address>123 Main St.</Address>
</Person>

또 다른 일반적인 방법은 다음 코드에서처럼, WriteStartObject 및 WriteEndObject를 전혀 사용하지 않고 사용자 지정 래퍼 요소를 작성하거나 래퍼 작성도 함께 건너뛰는 방법입니다.

xdw.WriteStartElement("MyCustomWrapper");
dcs.WriteObjectContent(xdw, p);
xdw.WriteEndElement();

이렇게 하면 다음과 유사한 XML이 생성됩니다.

<MyCustomWrapper>
  <Name>Jay Hamlin</Name>
  <Address>123 Main St.</Address>
</MyCustomWrapper>

참고
단계별 serialization을 사용하면 스키마에 유효하지 않은 XML이 생성될 수 있습니다.