Skip to content

Interfaces und abstrakte Klassen als Parameter – Teil 3

Die Lösung für ein Problem bin ich noch schuldig geblieben. Die beim letzten mal vorgestellte Lösung hatte den Nachteil, dass ein wichtiges Prinzip der Serviceorientierung nicht eingehalten wurde - Services share schema and contract, not class.

Die Lösung hierfür ist es die möglichen ServiceKnownTypes erst zur Laufzeit zu bestimmen. Folgendes Beispiel erläutert, wie es funktioniert:

C#:
  1. [ServiceContract]
  2. [ServiceKnownType("GetKnownTypes", typeof(KnownTypeHelper))]
  3. public interface ICustomerService
  4. {
  5.     [OperationContract]
  6.     void AddCustomerInterface(ICustomer customer);
  7.  
  8.     [OperationContract]
  9.     void AddCustomerBase(CustomerBase customer);
  10. }
  11.  
  12. public static class KnownTypeHelper
  13. {
  14.     public static IEnumerable<Type> GetKnownTypes(ICustomAttributeProvider provider)
  15.     {
  16.         List<Type> knownTypes = new List<Type>();
  17.         knownTypes.Add(typeof(SimpleCustomer));
  18.         knownTypes.Add(typeof(ExtendedCustomer));
  19.         return knownTypes;
  20.     }
  21. }

Die Klasse KnownTypeHelper stellt durch die Funktion GetKnownTypes die Typen für den Service bereit, die bei der Serialisierung und Deserialisierung genutzt werden sollen. Zu beachten ist das geänderte ServiceKnownType-Attribut am Interface ICustomerService.
Mit diesem Ansatz wird sowohl Polymorphismus unterstützt und gleichzeitig die Prinzipien der Serviceorientierung eingehalten.

Anmerkung: Es sollte offensichtlich sein, dass in der Methode GetKnownTypes die Typen dynamsich bestimmt werden können. So wäre es denkbar diese aus einer Konfiguration zu laden und/oder per Reflection zu bestimmen.

Categories: Programming, Web.

Tags: , , , ,

Comment Feed

One Response



Some HTML is OK

or, reply to this post via trackback.

Continuing the Discussion

  1. [...] Aber keine Sorge, auch für dieses Problem gibt es eine Lösung in Teil 3. [...]

WP SlimStat