HowTo: Microsoft p&p – Web Service Factory / Service Factory (Teil 1: Grundlagen & ASMX Variante)

image

In dem vorherigem HowTo ging es allgemein um Software Factories von dem patterns&practices Team – heute widmen wir uns mehr der Web Service Factory – auch Service Factory genannt.

Wichtigste Ressource:

Auf der MSDN Seite der Web Service Factory gibts einen groben Überblick was es alles für Quellen gibt – die meisten Sachen sind allerdings auf Codeplex.

 

Service Factory installieren und die HOLs dazu installieren:

Im MS Downloadbereich kann man den aktuellen Release (vom Dezember 2006) runterladen, dieser beinhaltet jeweils für C#:

  • ASMX Services
  • WCF Services

Nach der Installation hat man dann im Visual Studio 2 neue Projekttypen:

image

Dazu (um die ganze Sache mehr zu verstehen) würde ich noch die HOLs ebenfalls runterladen. Im nächsten Schritt werde ich grob das Resultat des HOLs erklären.
Es gibt diese HOLs einmal für ASMX Services und WCF Services – ich werde ganz kurz auf die Struktur von der ASMX Variante eingehen und später aber direkt mit WCF arbeiten, da dies in der Zukunft ASMX ablöst. Ich würde jedem empfehlen, die Exercise mal durchzugehen, man braucht grob 1-2h dafür.

Erklärung an den HOLs in der ASMX Variante:

  • Start (nachdem man sich durch die Wizards geklickt hat):

image

Man kann den Aufbau grob in 3 Teile gliedern:

  • BusinessLayer
  • DataLayer
  • ServiceLayer

In dem BusinessLayer (BusinessEntities/BusinessLogic) werden die einzelnen Klassen angelegt, die wir benötigen um die Daten darzustellen und eine gewisse Logik enthalten.
Der DataLayer gibt direkt Zugriff auf eine Datenbank – ideal ist natürlich MS SQL, aber es müsste auch Oracle und co. gehen – mit den Create/Read/Update/Delete Befehlen.
Im Servicelayer machen wir dann unsere Operationen zugänglich.
Jede Schicht ist nur lose miteinander gekoppelt – zum Beispiel hat der Service Layer ebenfalls ein DataType: Ob man diesen jedoch braucht, hängt ganz vom eigenen Geschmack ab. Man kann es nutzen, muss aber nicht.

Grobe Erläuterung der einzelnen Projekte:

  • Coho.ClubServices.Membership.DataAccess:
    • Zugriffsschicht auf Datenbank und gibt dieses an die BusinessEntities weiter
  • Coho.ClubServices.Membership.BusinessEntities:
    • Logische Daten
  • Coho.ClubServices.Membership.BusinessLogic:
    • Irgendwelche logischen Operationen oder Managementklassen um die Entities zu bearbeiten etc.
  • Coho.ClubServices.Membership.DataTypes:
    • Mapping zwischen den Entities die man in dem Service benutzt und den eigentlichen BusinessEntities
  • Coho.ClubServices.Membership.ServiceContract:
    • Beschreibt, welche Operationen generell möglich sind - hier sind nur Interfaces vorhanden
  • Coho.ClubServices.Membership.ServiceImplementation:
    • Die Implementierung des Contracts
  • Coho.ClubServices.Membership.Host:
    • Hostet die Service Implementierung

Das andere Projekt dient zum Testen des Service.

  • Ende (nach Exercise 10):

image

Wie man hier schon sieht – einige Projekte sind entfernt wurden.

Die Struktur am Anfang wurde vereinfacht. So beinhaltet jetzt das BusinessLogic Projekt auch neben der eigentlichen Logik auch die Entities und die Data Access Schicht.

image

Das sollte bereits zeigen, dass die Struktur auch jeweils an die Bedürfnisse angepasst werden kann.

Im nächsten HowTo wird es dann um die WCF Variante gehen und wie man dies praktisch implementiert.

 

Links:

Grundlagen HowTo
patterns&practices Team @ MSDN
Web Service Factory @ MSDN
Web Service Factory / Service Factory @ Codeplex
Download: Web Service Factory Release Dezember 2006
Hands-on-Lab mit ASMX und WCF

Letzte Posts

  • image_thumb.png
    NuGet Package Restore & Build Server wie z.B. AppVeyor

    NuGet ist ja mittlerweile weit verbreitet, aber eine Frage stellt sich natürlich immer noch: Checkt man die NuGet Packages ein oder nicht? In meinem kleinen Side-Projekt, welches auf GitHub liegt und ich über AppVeyor auch bauen lasse nutze ich das Package Restore Feature von NuGet, d.h. in meinem Repository befindet sich kein NuGet Package mehr, […]

  • image.png
    Microsoft Account Login via ASP.NET Identity

    Der Microsoft Account ist die zentrale Identifikationsstelle in der “Consumer-Microsoft-Welt”, allerdings ist das Einbinden eben dieser in die eigene Applikation eher schwierig. Das “Live SDK” ist nun unter dem OneDrive Dev Center zu finden und ganz professionell wurden auch alle Links zum alten Live SDK damit unbrauchbar gemacht. Beim Microsoft Account ist es auch unmöglich […]

  • image.png
    Zeitgesteuerte Azure WebJobs – so einfach kann Azure sein

    Das noch in Entwicklung befindliche Azure WebJob SDK bietet einige coole Features zum Verarbeiten und Bereitstellen von Daten. Bekanntes Beispiel ist das Sample welches auf eine Azure Queue lauscht und sobald ein Item da vorhanden ist anfängt dies zu verarbeiten. Szenario: Zeitgesteuerte Aktivitäten – ohne Queue und co. Mein Szenario war allerdings wesentlich trivialer: Ich […]

  • image.png
    Get Involved in OSS! Ja, aber wie geht das denn mit GitHub?

    Auch im .NET Lager gibt es Bewegung im OSS Bereich und es gibt verschiedene Arten wie man bei einem Open Source Projekt “Contributed”. Was zählt alles zu “Contribution”? Unter “Contribution” läuft eigentlich alles – ob es Fragen/Probleme zu dem Projekt via Issues ist oder Dokumentation nachreicht oder ob man darüber bloggt oder das Projekt vorstellt. […]

  • HowTo: Web.config samt eigener ConfigSection zur Laufzeit ändern

    In dem HowTo geht es darum wie man die Web.config zur Laufzeit ändert und was es dabei zu beachten gilt. Das ganze klappt auch mit komplexeren ConfigSections. Eigene ConfigSection? Vor einer ganzen Weile habe ich mal über das Erstellen einer eigenen ConfigSection geschrieben – im Grunde nutzen wir jetzt fast dieselbe Config. Zur Laufzeit? Startet […]

Support us!