Für das Layout von WCF-Projektstrukturen gibt es relative klare Empfehlungen, leider sind die in den Visual Studio Templates nicht abgebildet. Im Gegenteil, es wird von vielen Architekten und Entwicklern im WCF-Umfeld empfohlen, komplett auf diese Templates zu unterstützen. Es wird einfach zu viel gemacht, dass gar nicht notwendig ist und das eine saubere Trennung erschwert. Die Empfehlung für WCF-Projekte sieht vor, dass Contracts, egal ob Data- oder ServiceContract[s] in einem separaten Assembly (Class-Library) abgelegt werden. Die Implementierung der Services und weiterer Schichten kann dann, wie bei WebService oder anderen Projekten durchgeführt werden.
Assemblies:
- Contract
- Service (evtl. als Facade), ggf. als IIS-Projekt
- Datalayer
Oft wird auch oft empfohlen, dass man eine Fassaden-Architektur einzieht, wobei dass sehr umstritten ist. In der Fassade wird die spezielle Behandlung von FaultContract(s) durchgeführt, Artikel zu WCF-Exception Handling "Exception Handling in WCF using Fault Contract". Außerdem kann man die Fassade sehr gut dazu benutzen, Exception-Informationen von der Außenwelt zu verbergen.
Sind die Contracts sauber in dem separatem Assembly programmiert, kann dieses Assembly in .NET-Clients verwendet werden. Dadurch spart man sich die "hässliche" Generierung von Services auf dem Client. In allen Projekten, die ich durchgeführt habe, hat sich das als der beste Weg herausgestellt. Allerdings ist darauf zu achten, dass nur ein Vertrag in dem Assembly eingeführt wird. Die Implementierung von Logik hat in den Verträgen nichts zu suchen und würde die Unabhängigkeit von Client und Service verhindern. Ist das der Fall, hat man eine bessere .NET Remoting Lösung erstellt. Nur noch einmal zur Klarstellung, dass Contract-Assembly muss nicht genutzt werden, aber es ist sauberer für .NET Clients.
Keine Kommentare:
Kommentar veröffentlichen