Sử dụng DataContractResolver tùy chỉnh trong WCF, để vận chuyển cây thừa kế liên quan đến generics

Question

Tôi có một dịch vụ WCF, trong đó có các phép toán chấp nhận một lớp cơ sở không chung chung làm tham số.

[DataContract] 
class Foo 
{ ... } 

lớp cơ sở này được lần lượt di truyền, bởi lớp Generics như

[DataContract] 
class Bar<T> : Foo 
{ ... } 

Để có được điều này để làm việc, tôi muốn trước đây phải đăng ký KnownTypes cho lớp Foo, và có những bao gồm tất cả các biến thể có thể có của Bar (chẳng hạn như Bar<string>, Bar<int> và thậm chí Bar<List<string>>).

Với DataContractResolver trong .NET 4, tuy nhiên, tôi sẽ có thể xây dựng trình phân giải lưu trữ đúng cách (và khôi phục) các lớp.

Câu hỏi của tôi:

1. đang DataContractResolvers thường chỉ được sử dụng ở phía bên dịch vụ, chứ không phải bởi các khách hàng? Nếu vậy, điều đó sẽ hữu ích như thế nào trong kịch bản này?

2. Tôi có sai khi viết một DataContractResolver mà tuần tự hóa tên loại đủ điều kiện của một loại chung chung, chẳng hạn như Bar`1[List`1[string, mscorlib], mscorlib]? Không thể cùng một DataContractResolver ở phía khách hàng khôi phục các loại này?

Answer 1

Tôi hy vọng rằng để làm việc ở cả hai đầu, nhưng tôi không chắc đó là một ý tưởng tuyệt vời; nó đòi hỏi cấu hình phụ, và sẽ không làm việc trên Silverlight vv Nhưng nó có thể sẽ làm việc cho "đầy đủ" .NET với cùng một bit ở mỗi đầu.

Answer 2

Không biết trường hợp sử dụng điển hình cho DataContractResolver là gì, nhưng theo bài viết này (MSDN on DataContractResolver) điều này sẽ dễ dàng được thực hiện với "SharedTypeResolver" và chia sẻ các hội đồng có chứa hợp đồng.

Một lời cảnh báo: Vì vậy, trong khi điều này có vẻ là có thể tôi không chắc chắn nếu đây là một ý tưởng tốt từ một quan điểm thiết kế, vì điều này sẽ làm suy yếu sự biểu cảm của hợp đồng. Những loại đó sẽ tạo đường hầm cho hợp đồng và làm hỏng khả năng tương thích với các ngôn ngữ lập trình khác, và điều này sẽ dẫn đến câu hỏi nếu sử dụng một chuẩn mở như SOAP là giải pháp đúng đắn ngay từ đầu. DataContract có cho không cụm chia sẻ ...

Answer 3

Tôi đã sử dụng DataContractResolver trước đó; và đây là những phát hiện của tôi:

1. Cả khách hàng và máy chủ đều yêu cầu người giải quyết; như serialization và deserialization diễn ra ở cả hai đầu. Rõ ràng, cùng một Resolver được sử dụng.
2. Tên loại là một phần tiêu chuẩn của thông tin mà DataContractSerializer tạo ra.Tuy nhiên, nó chỉ là loại TÊN, không phải là một đầy đủ (lắp ráp) tên đủ điều kiện

Về cơ bản, một trình giải quyết tùy chỉnh cho phép bạn thêm nó vào khách hàng WCF của bạn và máy chủ như Hành vi:

`foreach (OperationDescription operation in myWCFService.Description.Endpoints[0].Contract.Operations) 
    { 
     operation.Behaviors.Find<DataContractSerializerOperationBehavior>() 
      .DataContractResolver = new MyDataContractResolver(); 
    }` 

Đối khách hàng, bạn cũng làm như vậy:

 `foreach (var operation in base.ChannelFactory.Endpoint.Contract.Operations) 
    { 
    operation.Behaviors.Find<DataContractSerializerOperationBehavior>() 
     .DataContractResolver = new MyDataContractResolver(); 
    }` 

Trình phân giải của tôi tự động tải các loại từ vị trí được định cấu hình và dựa trên một số thuộc tính, lưu trữ chúng. Tôi có thể cung cấp cho bạn một số mã mẫu nếu bạn thích - tất cả đều khá cơ bản.

KnownTypeAttribute (ví dụ: sử dụng phương thức được cung cấp để trả về tất cả các loại đã biết) cũng có thể sử dụng được; nhưng trình phân giải tùy chỉnh cho phép một cách tiếp cận linh hoạt hơn, chẳng hạn như tải động (ví dụ: hệ thống plugin) và thực hiện ánh xạ của riêng bạn (Type => type name và ngược lại)