직렬화는 Dependency Injection 사용을 금지합니까?

간단한 질문 : C #의 직렬화에는 기본 생성자가 필요하다는 것을 알고 있습니다. 이것은 (내 독서에서, 일반적으로 DI의 선호 스타일 생성자는 DI를 주입 사용의 가능성을 제거하는 것입니다 ^{[표창장은 필요로했다]를} ). 그래서 그것은 실제로 하나의 상황입니까, 아니면 뭔가 빠졌습니까?

(질문) : IoC 컨테이너는 어떻게 든이 트레이드 오프를 회피합니까?

표준 직렬화 메커니즘을 사용하여 개체를 직렬화 해제하고 C #의 한 단계 에서 기존의 다른 개체에 대한 종속성을 주입 할 수 없습니다 . 대신 속성 주입을 사용해야합니다. 먼저 디시리얼라이저를 사용하여 객체를 생성 한 후 종속성을 주입해야합니다. 대부분의 실제 응용 프로그램의 경우이 단점을 실제 단점으로 생각하지 않습니다. 직렬화 가능한 데이터 모델 클래스가 있고 다른 비 데이터 모델 클래스에 대한 종속성이있는 경우 데이터 모델 클래스에 있는지 확인해야합니다 이미 너무 많은 책임이 있습니다.

그것이 정말로 당신을 귀찮게한다면, 직렬화 가능 객체를 데코레이터 클래스로 감싸서 생성자를 통해 디 직렬화 기와 추가 종속성을 전달할 수 있습니다. 그런 다음 래퍼는 생성자에서 두 단계 (랩핑 된 객체의 직렬화 해제 및 속성 삽입)를 실행합니다.

나는이 문제를 다음과 같이 해결하고있다 : 의존성 팩토리 주입. 이러한 팩토리에서는 먼저 컨테이너에 등록 된 종속성을 해결 한 다음 나머지 모든 데이터를 "직렬화 해제"합니다. json.net은 기존 객체의 필드를 채울 수 있습니다.

팩토리 코드는 IoC 컨테이너의 와이어 링 코드와 함께 사용 container.Resolve되므로 팩토리 내부를 사용 하는 것이 규칙에서 위반하는 것으로 생각하지 않습니다 . 규칙 container은 코드의 한 곳에서만 사용해야합니다. 모든 배선이 발생하는 곳.

현재로서는 리플렉션을 사용 하여이 프로세스를 자동으로 만들려고합니다 (내가 그 방법을 테스트 한 것과는 반대입니다). 예, json.net deserialization 자체에는 남아있는 것이 많지 않으며 일부는 사용자 정의 코드로 대체되지만 왜 귀찮게 생각합니다.

또한이 문제에 대한 최종 생각 / 결정은 무엇입니까? 이 게시물을 읽은 후 두 가지 방법이 있습니다. deserialize, inject; 주입 한 다음 역 직렬화 (인구)합니다. 그리고 나는 여전히 내 방식이 더 낫다는 것을 알았습니다. 이것에 반대되는 주장을 듣고 기뻐할 것입니다 (저는 내 방식이 더 좋을 수도 있지만 실패한 곳에서 약간의 추측만으로도 좋은 대안을 생생하게 상상할 수는 없습니다)