Ich habe daran gearbeitet, die App-Ebene und die Web-Ebene einer Web-Anwendung aufzuteilen. In der App-Ebene konnte ich die Geschäftslogik in eine Reihe von Services unterteilen, die mit WCF-Proxys bereitgestellt wurden. Das Problem besteht darin, dass diese Dienste mit einer anderen Legacyanwendung kommunizieren, die ein großes CLR-Objekt als primäres Kommunikationsmittel verwendet. Um die Dinge schnell zu halten, hatte ich eine Kopie dieses Objekts in der Sitzung aufbewahrt, nachdem ich es das erste Mal erstellt hatte. Jetzt weiß ich, dass WCF Sitzungen durchführen kann, aber der Sitzungsspeicher ist pro Dienst, während meine Geschäftslogik jetzt in mehrere Dienste aufgeteilt ist (wie es sein sollte).
Jetzt die Fragen:
Dies ist wahrscheinlich nicht das erste Mal, dass jemand ein großes Geschäftsobjekt auf dem Server hat. Leider muss ich dieses Objekt wirklich pro Benutzer zwischenspeichern (daher die Sitzung).
Es ist möglich, dass die Antwort offensichtlich ist und ich es einfach nicht sehe. Hilfe bitte!
Soweit ich WCF verstehe, ist es so staatenlos wie es nur sein könnte. In einer Sitzung können Sie sich an einige Werte in Ihrem Service erinnern, aber Objekte sollen nicht außerhalb des Rahmens einer Sitzung liegen.
Deshalb würde ich denken, dass Sie in Schwierigkeiten sind.
Natürlich könnte es eine Möglichkeit geben, Objekte zwischen Sitzungen zu speichern und auszutauschen, die ich nicht kenne (ich benutze WCF, aber ich weiß nicht viel darüber, abgesehen davon, was ich für mich brauche) / p>
(Wenn es eine Möglichkeit gibt, Objekte zwischen Diensten zu teilen, würde es wahrscheinlich nur auf Diensten funktionieren, die Sie selbst hosten. IIS-Hosting könnte Ihren Dienst manchmal wiederverwenden)
Vielleicht können Sie dieses Objekt in einen Singleton-Service verpacken. Dies ist ein Dienst mit nur einer Instanz, der zwischen den Anrufen nicht zerstört wird. Da Sie für jeden Benutzer ein Objekt benötigen, muss dieser Dienst eine Liste von ihnen verwalten, und die aufrufenden Dienste müssen die erforderlichen Authentifizierungsdaten (oder Sitzungs-IDs) bereitstellen. Vergessen Sie nicht eine Zeitüberschreitung, um nicht benötigte Objekte loszuwerden ...
Erstellen Sie einen Fassadendienst , der das große CLR-Objekt im Auftrag der anderen App-Tier-Services hostet. Es kann als Adapter verwendet werden und ermöglicht spezifischere Sitzungskennungen für die fortgeschrittenen App-Tier-Services, die Sie erstellt haben. Die Fassade kann eine Sitzungs-ID wie eine GUID bereitstellen, die Ihre App-Tier-Services verwenden können, um eine Verbindung mit dem großen CLR-Objekt herzustellen.
Dies bietet einige Vorteile:
Einige Ihrer App-Ebenen benötigen möglicherweise überhaupt nichts über das CLR-Objekt. Sie kommunizieren nur mit der Remote-Fassade.
Der Host 'large CLR object' behält das Sitzungsobjekt für die anderen Dienste bei, die es jetzt freigeben können.
Die App-Tiers haben jetzt eine Fassade, über die sie mit dem Legacy-Service sprechen. Wenn Sie diesen alten Service umgestalten, muss die App-Ebene nicht geändert werden.
Abhängig von Ihrer Konfiguration können Sie die Fassade möglicherweise über ein in proc-Hosting hosten, was zu einer Verbesserung der Retain-Leistung führt, die Sie suchen.
Das Aufteilen in Subdienste scheint eine gute Idee zu sein, wenn Sie die App über eine Farm verteilen möchten. Es ist jedoch wichtig zu beachten, dass jedes Mal, wenn ein Objekt die Anwendungsdomänengrenze bei der Variation überschreitet, es in den Speicher kopiert werden muss.
Alles hängt davon ab, wie groß das Objekt ist und welche Art von Daten es enthält.
Wenn Sie das Objekt nicht übergeben möchten, weil es zu groß ist, möchten Sie möglicherweise eine Abfrage-API für den Dienst erstellen, der es empfängt. Auf diese Weise könnten Sie dieses Objekt manipulieren, ohne kostspielige Serialisierung oder Remotierung durchführen zu müssen.
Halte es einfach. Da Sie in Ihrer WCF bereits auf Session zugreifen können, können Sie die SessionID von dort aus verwenden. Jetzt:
Erstellen Sie irgendwo ein statisches Wörterbuch, wobei der Schlüssel Ihre Sitzungs-ID ist und der Wert das Geschäftsobjekt ist, das Sie speichern möchten.
Anstatt auf das Geschäftsobjekt in der Sitzung zuzugreifen, greifen Sie einfach auf die Sitzungs-ID zu und rufen Sie das Geschäftsobjekt aus dem Wert Ihres Wörterbuchs ab.
(Sie können auch eine Art von Zwischenspeicherung verwenden, wenn Sie möchten, zum Beispiel System.Web.Caching , so dass Sie das Wörterbuch nicht manuell aufräumen müssen)
Tags und Links wcf