Serialization 지침
클래스는 컴파일된 뒤에는 serialize 가능으로 지정할 수 없기 때문에 새 클래스를 디자인할 때 serialization을 고려해야 합니다. 이 경우 다음과 같은 질문을 해보아야 합니다. 이 클래스가 응용 프로그램 도메인을 가로질러 전송되어야 하는가? 이 클래스가 Remoting에 사용될 것인가? 사용자가 이 클래스로 무슨 작업을 할 것인가(serialize되어야 하는 이 클래스에서 새 클래스를 파생할 것인지 여부)? 확실하지 않은 경우에는 클래스를 serialize 가능으로 표시합니다. 다음 중 하나가 true인 경우 이외에는 모든 클래스를 serialize 가능으로 표시하는 것이 좋습니다.
클래스가 응용 프로그램 도메인을 가로지르지 않습니다. serialization이 필요하지 않고 클래스가 응용 프로그램 도메인을 가로질러야 하는 경우 클래스를 MarshalByRefObject에서 파생합니다.
클래스가 클래스의 현재 인스턴스에만 적용할 수 있는 특수 포인터를 저장합니다. 예를 들어 클래스에 관리되지 않는 메모리 또는 파일 핸들이 포함된 경우 이러한 파일이 NonSerializedAttribute 특성으로 표시되었는지 확인하거나 클래스를 serialize하지 마십시오.
클래스 데이터 멤버에 중요한 정보가 들어 있습니다. 이 경우에는 클래스를 serialize 가능으로 표시하고 중요한 정보가 포함된 개별 데이터 멤버는 NonSerializedAttribute 특성으로 표시하는 것이 좋습니다. 다른 방법은 ISerializable 인터페이스를 구현하여 필요한 필드만 serialize하는 것입니다.
클래스를 serialize 가능으로 표시할 때 수반되는 보안 문제를 알아두어야 합니다. 클래스 또는 클래스 생성자의 CodeAccessPermission에 대한 Link Demand 또는 Inheritance Demand는 동일한 CodeAccessPermission에 대한 해당 요청을 구현하는 사용자 지정 serialization 또는 기본값에 의해 우회될 수 있습니다. 자세한 내용은 SecurityAction 열거형을 참조하십시오. 클래스에 권한에 대한 Link Demand가 있는 경우 런타임에서는 직접 호출자만 검사하여 호출자에게 권한이 부여되었는지 확인합니다. .NET Framework 클래스 라이브러리 코드는 Microsoft의 강력한 이름으로 서명되며 항상 완전 신뢰가 허용됩니다. 모든 코드는 완전 신뢰가 부여된 코드를 사용하여 링크 타임 보안 검사를 우회할 수 있습니다. 예를 들어 serialization의 경우 필요한 serialization 권한이 없는 악의적 코드가 BinaryFormatter와 같은 완전히 신뢰되는 .NET Framework 포맷터 중 하나를 호출하고 권한에 대한 링크 요청 검사를 우회할 수 있습니다.
참고 항목
기타 리소스
이진 Serialization
Remote Objects
XML 및 SOAP Serialization
Security and Serialization
Copyright © 2007 by Microsoft Corporation. All rights reserved.