Layering einen WCF-Dienst, den richtigen Weg

Question

Meine Frage ist eher eine architektonischen Natur, weniger beteiligt mit der tatsächlichen Umsetzung.

Ich habe eine API auf WCF basierte bauen, kann aber nicht wirklich entscheiden, wie die PL von der BL zu trennen. Ich habe meinen Dienst dünn gemacht, so dass es nur ein Minimum an Implementierung hält, so etwas wie:

public TagItemResponse TagItem(TagItemRequest request)
{
   return (new ItemTagRequestProcessor()).GetResponse(request);
}

als natürlich die erste Frage stellt sich, in welche Schicht gehören die RequestProcessors? Ich denke, es wäre falsch, sie eine Fassade zu nennen, aber zugleich, sie haben nichts mit Präsentation zu tun. Was jetzt, habe ich beschlossen, dass sie doch in der PL gehören. Die Prozessor Methoden meine DTO nehmen (Datacontracts) als Eingabe, die Anforderungsnachricht (Basisklasse) validieren, authentifizieren (Basisklasse) und schließlich eine einzige DTO Antwort zurück, etwa so:

protected override void Process(TagItemRequest request, TagItemResponse response, Host host)
{
    var profile = ProfileFacade.GetProfile(host, request.Profile);
    var item = ItemFacade.GetItemId(host, request.Item);
    var tags = new List<Tag>();

    foreach (var name in request.Tags)
    {
        var tag = TagFacade.GetTag(profile, name);
        ItemFacade.TagItem(item, tag);
        tags.Add(tag);
    }

    ItemFacade.UntagItem(item, tags);
}

Nun frage ich mich, warum brauche ich die Fassade Klassen 1: 1 in Bezug auf meine Business-Objekte. Zum Beispiel habe ich eine HostFacade, die zwischen dem hostDAO und den Prozessoren als eine Schicht wirkt. Es gilt jedoch nur sehr wenig Logik, es lediglich die DAO Anrufe abwickelt.

public static Host GetHost(HostDTO dto)
{
   return HostDAO.GetHostByCredentials(dto.Username, dto.Password);
}

Frage: Ich könnte auch die Prozessoren verschmelzen und die Fassaden, rechts

Ich habe zu diesem Thema viele Artikel / Bücher lesen, aber ich kann immer noch nicht auf die ‚richtige‘ Art und Weise absetzen zu gehen und neigt dazu, einen anderen Ansatz ich die Frage stelle jedes Mal zu wählen. Ich frage mich, ob ein richtiger Ansatz überhaupt existiert.

Ich habe festgestellt, zb das doFactory Beispiel, wo sie direkt aus der Service-Implementierung auf die DAO-Klassen gesprochen. Ich weiß wirklich nicht so, wie die meisten Servicecontract Methoden eine gewisse Logik teilen, und sich somit gut mit gemeinsamen Basisklassen für den Einsatz verleihen.

Ich habe festgestellt, auch andere Beispiele, bei denen nur die Fassaden von innerhalb der Dienste genannt werden, aber das scheint für sehr feinkörnig Nachrichten nur gut zu arbeiten. Meine Nachrichten sind ‚fett‘ und Composite, um die Anzahl der Anrufe an den Dienst so weit wie möglich zu reduzieren. Meine zusätzliche Verarbeitungsschicht scheint das mein eigentliches Problem sein.

Wahrscheinlich gibt es keine einheitliche Antwort auf die Frage, wie man richtig einen WCF-Dienst Schicht, aber hoffentlich gibt es dort einige von Ihnen mit einer Stellungnahme, die entweder meinen Instinkten entsprechen oder ein neues Licht auf das Thema für mich vergossen.

Thanx!

Geoffrey

Answer 1

Zuerst Ich gehe davon aus, dass durch PL Sie Präsentationsschicht bedeuten, nicht Schicht Persistenz?

Wenn ein geschichtetes Anwendungsdesign implementieren, sollte die Hauptfrage immer sein. Ich kann die Implementierung einer unteren Schicht ersetzen, ohne dass die Durchführung der Schicht auswirkt (s) über

Dies ist in der Regel am besten durch die Persistenz-Schicht dargestellt. Wenn Sie von SQL Server wechseln 2008 MySQL zum Beispiel der Persistenz-Schicht ändert (natürlich). Aber sind Änderungen in der Business-Schicht auch notwendig? Zum Beispiel hat die Fang SqlException Instanzen Business-Schicht, die nur von SqlClient geworfen werden? In einem guten Design, muss die Business-Schicht keine Änderungen an alle.

Das gleiche Prinzip der Trennung gelten sollte zwischen Business-Schicht und Präsentationsschicht.

In Ihrem Beispiel, würde ich sagen, dass der ItemTagRequestProcessor nicht in der Präsentationsschicht sein sollte. Erstens, es hat nichts mit Präsentation zu tun hat, zweitens, die Umsetzung der Bearbeitung eines Antrags ist kein Problem für die Präsentationsschicht. Vergleichen Sie es mit einer Web-Anwendung, ein TagItemResponse an einen Kunden zu präsentieren ist das Anliegen der Bahn (Präsentation) Schicht. eine Instanz von TagItemResponse Abrufen ist das Anliegen einer Schicht unterhalb der Präsentationsschicht.

Die Entscheidung, ob eine Fassade zwischen Ihrer Business-Schicht und Persistenz-Schicht haben, ist schwierig. Ich in der Regel nicht implementieren eine Fassade, weil diese eine (in der Regel nicht erforderlich) Schicht Indirektionsebene hinzufügt. Außerdem sehe ich nicht ein Problem in Methoden Persistenz-Schicht Methoden direkt von Business-Schicht aufrufen. Wenn nur nehmen Sie das gleiche Prinzip in Betracht. Sie können die Persistenz-Schicht Implementierung ändern, ohne die Business-Schicht Implementierung zu beeinflussen

Mit freundlichen Grüßen

Ronald Wildenberg