이 같은 직렬화 속성 예제 몇 본 적이

사용 직렬화 이유 :이 같은 직렬화 속성 예제 몇 본 적이

[Serializable()] 
      public class sampleClass 
      { 
       public int Property1{ get; set; } 
       public string Proerty2{ get; set; } 

       public sampleClass() { } 
       public sampleClass(int pr1, int pr2) 
       { 
        pr1 = pr1; 
        Name = pr2.ToString(); 
       } 
      }

나는 이것이 어떻게 작동하는지 이해에 대한 좋은 이해를 가지고,하지만 msdn에서 결코 :

직렬화 개발자는 개체 의 상태를 저장하고 필요에 따라 개체를 다시 만들 수 있으므로 개체 저장소와 데이터 교환을 제공 할 수 있습니다. 개발자는 직렬화를 통해 웹 서비스를 통해 원격 응용 프로그램에 개체를 보내고 한 도메인에서 다른 도메인으로 개체를 전달하거나 개체를 방화벽을 통해 XML 문자열로 전달하거나 보안 유지 또는 응용 프로그램 간의 사용자 별 정보

하지만 문제는 내 코드 예제에서 사용하지 않는 것입니다. 데이터베이스에서 데이터를 검색하는 데 사용되는 객체로 특별한 것은 없습니다. 직렬화를 사용할 때와 사용하지 않을 때의 다른 용도는 무엇입니까? 예를 들어, 더 안전하기 때문에 항상 serializzation을 사용해야합니까? 이런 식으로 느린가?

업데이트 : 모든 좋은 답변을 주셔서 감사합니다

출처

2012-06-08 user194076

Out-of-Proc/SQL을 사용할 때 SessionState에 저장 될 수 있습니까? 이러한 세션 모드에는 직렬화가 필요합니다. – vcsjones

질문에 답하고 있는지 잘 모르겠습니다. 실제로 "왜 객체를 직렬화하고 싶습니까?"라고 묻고 있습니까? –

@Kirk Woll, 맞습니다. – user194076

직렬화가 당신에 또는 프로세스 경계에서 데이터의 표현을 이동하려는 언제든지 유용합니다.

개체를 디스크에 저장하는 것은 많은 자습서에서 볼 수있는 간단한 예입니다.

보다 일반적으로 직렬화는 웹 서비스간에 데이터를 전송하거나 데이터베이스에서 데이터를 유지하는 데 사용됩니다.

출처

2012-06-08 19:46:09

왜 개체를 디스크에 저장합니까? – user194076

한 예 : 데이터베이스 백엔드를 사용하지 않는 응용 프로그램의 사용자 구성 (응용 프로그램에서 객체로 표시)을 저장합니다. –

@ user194076 : 예를 들어, 게임 개체의 상태를 일시에 저장 한 다음 게임이로드 될 때 다시 빌드함으로써이 메서드로 게임의 저장 기능을 구현할 수 있습니다. – Tudor

제공된 MSDN 견적은 직렬화가 유용 할 때 데이터를 전송하거나 저장하는 데 대해 설명합니다. 파일에 쓰는 것은 직렬화이며 네트워크를 통해 객체를 보내려면 직렬화가 필요합니다.

데이터베이스에서 단일 응용 프로그램으로 객체를 채우는 경우 실제로 직렬화는 전혀 문제가되지 않습니다. 직렬화 클래스를 이미징하면 보안이나 성능에 아무런 영향을 미치지 않습니다. 필요하지 않으면 걱정할 필요가 없습니다.

또한 [Serializable]은 주로 BinaryFormatter과 관련이 있지만 실제로는 그 이상의 많은 serializer가 있습니다. 예를 들어 JSON 또는 XML을 통해 개체를 노출하려는 경우 - 둘 다 직렬화가 필요하지만 어느 것도 필요하지 않은 경우 [Serializable]이 필요합니다.

출처

2012-06-08 19:50:54

데이터베이스에서 개체를 채우지 않고 다른 형식의 직렬화를 수행합니까? DataContractSerializer와 같은 자동 serializer를 사용하든 수동으로 데이터베이스간에 필드를 이동하거나 또는 데이터베이스에서 필드를 이동하는지 여부에 관계없이 여전히 직렬화 중입니까? –

@Eric 그것은 persistence */* materialization *의 형식입니다. 그렇지만 저는 개인적으로 그 serialization/deserialization을 부르지 않을 것입니다. 나는 RDBMS가 직렬화의 일반적인 정의에 맞는다고 생각하지 않는다. 비록 객체를 직렬화하고이를 RDBMS 또는 NoSQL 저장소에 BLOB로 저장하는 것은 일반적이지 않다. –

의미론, 제 생각입니다. Wikipedia 기사에서는 이러한 차이를 구분하지 않고 실제로 데이터베이스에 데이터를 저장하는 ISerializable을 구현하는 무언가를 구현할 수 있습니다. –

간단한 예 : 응용 프로그램 설정을 저장할 사용자 지정 모양이 있다고 가정 해보십시오.

<?xml version="1.0" encoding="utf-8" ?> 
<Settings> 
    <Setting1>Foo</Setting1> 
    <Setting2>Bar</Setting2> 
</Settings>

당신은 단순히 직렬화 및 설정을 역 직렬화 할 수 XmlSerializer를 사용 :

namespace My.Namespace 
{ 
    [Serializable] 
    public class Settings 
    { 
     public string Setting1 { get; set; } 

     public string Setting2 { get; set; } 
    } 
}

당신은 다음 파일을 같은 XML 파일을 가질 수 있습니다.

ASP에 채우려는 경우 셰이프를 직렬화 할 필요가 있습니다.NET의 ViewState

이들은 매우 기본적인 예이지만

출처

2012-06-08 19:54:15 aletrasg

재미있는 점은'XmlSerializer'는'[Serializable]'에 대해 전혀 신경 쓰지 않는다. –

사실, 실제로는 단지 BinaryFormatter 인 – aletrasg

을 처리하는 것은 오직'DataContractSerializer'라고 생각한다. DataContractSerializer는 [DataContract]를 원하지만 BinaryFormatter 모드가없는 경우 기본값을 사용합니다. –

몇 가지 답변은 일반적으로 직렬화를 사용하려는 이유의 이유를 포함 한 유용성입니다 보여줍니다. 특정 클래스의 속성이 [Serializable] 인 이유를 알고 싶다면 왜 이것이 수행되었는지 궁금 할 것입니다.

ASP.NET의 경우 기본 세션 상태 저장소는 InProc이며 모든 개체를 참조로 저장하고 힙에 둘 수 있습니다. 세션 상태를 저장하는 가장 좋은 수행 방법이지만 단일 작업자 스레드를 사용하거나 작업자 스레드가 변경 될 가능성이있는 경우 모든 세션 상태를 자동으로 다시 작성할 수있는 경우에만 작동합니다. 다른 상태 저장 모드 (StateServer 및 SQL Server)의 경우 ASP.NET 엔진이 저장 미디어로 보내기 전에 이진 serialization을 사용하여 이러한 개체를 먼저 serialize하므로 모든 세션 상태 개체를 직렬화 할 수 있어야합니다.

귀하의 경우에는 InProc 일 수 있습니다. 세션 상태에서 사용되는 모든 클래스를 Serializable으로 표시하고 테스트하는 한 가지 이유는 앞으로 웹 팜을 사용하기 위해이를 변경해야 할 필요가 있다는 것입니다. 이 점을 염두에두고 세션 상태 클래스를 설계하지 않으면 나중에 마이그레이션을 수행하는 것이 매우 어려울 것입니다.

또한 하나의 환경에서 Serializable 특성을 제거 할 수 있고 프로그램 "작동"이 있다고해서 다른 환경에서 작동한다는 것을 의미하지는 않습니다. 예를 들어 Visual Studio 테스트 웹 서버 (항상 InProc 세션 상태 모드 사용) 인스턴스와 개발 IIS 인스턴스에서 작동하지만 프로덕션 IIS 인스턴스는 다른 저장소 모드를 사용하도록 설정할 수 있습니다.

이러한 환경/구성의 차이점은 반드시 ASP.NET 응용 프로그램에만 국한되지는 않습니다. 이 작업을 수행 할 수있는 다른 응용 프로그램 엔진이나 이러한 독립 실행 형 응용 프로그램도 있습니다 (이러한 종류의 구성 가능한 환경을 구축하는 것은 어렵지 않습니다).

마지막으로, 다른 응용 프로그램에서 사용할 수있는 라이브러리로 작업 중일 수 있습니다. 일부는 직렬화 가능 방식으로 상태를 저장해야 할 수도 있고 그렇지 않을 수도 있습니다.

이러한 요소 때문에 최소한 라이브러리를 작성할 때는 간단한 값 클래스 또는 상태 관리 클래스를 [Serializable]으로 표시하는 것이 좋습니다. 이 클래스를 테스트하기위한 작업이 증가하고 직렬화 할 수있는 것에 대한 제한이 있습니다 (즉, 소켓 참조 또는 열린 파일 참조가 포함 된 클래스는 열린 외부 리소스를 직렬화 할 수 없으므로 직렬화에 적합하지 않을 수 있음) 그래서 이것을 과용하지 마십시오.

[Serializable]을 사용하면 속도가 느려지는 질문을 받았습니다. 아니, 그렇지 않을거야. 이 속성은 성능에 직접적인 영향을주지 않습니다. 그러나 응용 프로그램 환경이 오브젝트 직렬화로 변경되면 예에 따라 성능이 영향을받습니다. 객체를 힙에 저장하는 것보다 느린 직렬화 및 비 직렬화 작업입니다. [일부 루틴은 Serializable 속성을 찾은 다음 직렬화하도록 선택할 수 있지만 매우 드뭅니다. 일반적으로 ASP.NET과 같아서 관리자 나 사용자가 저장 매체를 변경할지 결정해야합니다.]

출처

2012-06-09 01:21:48

직렬화를 사용하거나 사용하지 않을 때는 다른 용도가 있습니다.

하나의 실질적인 예를 들어 보겠습니다.내 응용 프로그램 중 하나에서 XML 스키마 (XSD 파일) 요청 및 응답 XML 파일을 받았습니다. 내가 요청 XML 파일을 구문 분석하고 다시 여러 테이블에 정보를 저장해야합니다. 나중에 응답 XML을 적절히 준비하고 고객에게 보내야합니다.

Xsd2Code을 사용하여 C# 클래스를 생성했습니다. 따라서 요청 XML 파일을 구문 분석하면 은 생성 된 요청 클래스 객체에을 역 직렬화합니다. 그런 다음 객체의 속성을 요청 XML 파일에 나타나는 방식으로 액세스 할 수 있습니다. 응답 XML 파일을 생성하는 동안 내 코드에 채울 생성 된 응답 클래스 객체에서을 serialize하는 것만으로 간단하게 입니다. 이렇게하면 XML 파일보다는 C# 개체로 작업 할 수 있습니다. 나는 그것이 의미가 있기를 바랍니다. 내가이 어떤 식 으로든 보안과 관련된 생각하지 않습니다

더 안전하기 때문에

예를 들어, 난 항상 serializzation을 사용해야합니다.

출처

2012-06-09 17:19:42

이 같은 직렬화 속성 예제 몇 본 적이

답변

관련 문제