Derzeit haben wir 12 WCF-Projekte in unserer Lösung. Jedes Projekt ist im Wesentlichen ein eigener Endpunkt. Zum Beispiel ist das WCF-Projekt "Order" der Order.svc-Endpunkt. Diese 12 Endpunkte werden von einem einzelnen WebHost-Projekt bereitgestellt. Das WebHost-Projekt verfügt über 12 .svc-Dateien, die auf jede entsprechende Assembly / jeden Namespace zeigen.
Meine Frage dreht sich darum, ein Projekt (eine Assembly ... eine DLL) im Vergleich zu mehreren Projekten (mehrere Assemblies ... mehrere DLLs) zu verwenden. Was sind die Vorteile / Nachteile, wenn überhaupt? Das Endergebnis ist das gleiche ... Sie haben ein WebHost-Projekt, das diese Endpunkte anzeigt, die auf eine Assembly / einen Namespace zeigen. Außer Sie müssen nur eine .dll vs 12 .dll's im bin-Verzeichnis verwalten.
Für mich die Vorteile eines Projekts: Wartbarkeit - anstelle von 12 Projekten mit jeweils mehreren Referenzen auf unsere Schnittstellen, Datenverträge, Utilities usw. haben wir ein Projekt, bei dem die Referenzen in EINEM Spot gesetzt sind. Wir können dann die eine DLL bereitstellen und einen Lastenausgleich verwenden, um gleichmäßig zu verteilen. Selbst wenn wir explizit 3 Dienste pro Server hosten (also 4 Server), kann der Load Balancer sich anpassen, wenn ein Server ausfällt, und die anderen 3 Server haben das, was sie brauchen und kümmern sich automatisch um alles. (Ich denke, das gleiche gilt für 12 .dlls ... muss nur sicherstellen, dass alle 12 .dlls auf jedem Server sind).
Bauzeit - weniger Projekte = schnellere Bauzeit. Visual Studio muss nicht so viele Verknüpfungen und Kopien von .dll-Dateien ausführen. Schnellere Build-Zeit = produktiverer Entwickler und schnellerer Build und Deploy.
Ich habe derzeit ein paar Mitarbeiter, die daran interessiert sind, alle unsere WCF-Dienste in ein Projekt einzubinden. Für mich sind das alles WCF-Dienste, warum nicht in dasselbe Projekt? Die Endpunkte (.svc-Dateien) trennen sie voneinander. Ich habe auch die Frage gehört: "Wie steht es um ein totes Schloss?". Was ist damit? Ist das ein gültiges Problem? (Ich weiß es ehrlich gesagt nicht)
Es wurden auch Fragen gestellt, ob die .dll beschädigt wird. WENN es ist, dann sind alle Dienste ausgefallen. Nochmal ... ist das eine berechtigte Sorge?
Alle Beispiele, die ich von Microsoft und anderen gesehen habe, haben die WCF-Dienste in einem Projekt durch verschiedene Klassen getrennt. Schnittstellen sind in einem eigenen Projekt ... Daten werden in einem anderen Projekt übertragen und so weiter.
Also, was ist deine Meinung? Wie organisieren Sie mehrere WCF-Dienste in Ihrer Visual Studio-Lösung? Lerne mich.
Wir haben das auf die harte Tour gelernt. Wir hatten vor kurzem ein Projekt, bei dem wir mit jedem Service in einem eigenen Projekt begannen und am Ende alle Services im selben Projekt umsetzten. Die Hauptprobleme mit Dingen in verschiedenen Projekten sind:
Wir verwenden separate Projekte für Schnittstellen (Verträge) und Datentransferobjekte.
Wenn meine SVC-Dateien in der gleichen Assembly vorhanden sind, teilen sie im Allgemeinen einen bestimmten Zweck. Wenn die SVC genug gemeinsamen Zweck teilen, um in derselben Assembly zu existieren, dann teilt die Implementierung auch genug gemeinsamen Zweck, um in einer einzelnen Assembly zu existieren.
Es gibt kein Problem damit, sie in separaten Baugruppen zu haben, aber es gibt auch keinen Vorteil. Es geht vielmehr darum, eine klar strukturierte, pflegeleichte Lösung zu entwickeln - und ist weitgehend eine persönliche Präferenz / Standards / Stilfrage.
Trennen Sie die Implementierungen, wenn Sie sie normalerweise trennen würden, dh wenn sie signifikant unterschiedliche Ergebnisse liefern oder als separate Komponenten Ihrer Lösung fungieren. Wenn die einzelne Baugruppe unhandlich wäre, dann trennen Sie sie.
Konzentrieren Sie sich mehr auf Verträge und Implementierungen. Sie dienen verschiedenen (technischen) Zwecken, und Sie möchten möglicherweise die Verträge offenlegen, ohne die Implementierungen offenzulegen.
Nachdem ich all das gesagt habe, würde ich sie lieber in einer einzigen Assembly haben, aber getrennt durch klare Namensräume. Weniger Baugruppen sind oft einfacher zu verwalten.
Denken Sie daran, dass Sie Ihre Projekte nicht so bereitstellen müssen, wie Sie ihre Entwicklung verwalten. Sie können immer Dinge wie ILMerge verwenden, um dlls in einer DLL zu multiplizieren, als Teil eines Build-Schritts.
Ich empfehle immer, einige Dienste mit Hilfe der Software Factory (auch bekannt als Web Service Software Factory), Ссылка zu entwickeln, die dabei hilft, ein Bündel zu erzwingen von "Best Practices" aus den MSFT Patterns & amp; Praxis-Team. Es ist ein guter Weg, um einige Best Practices zu lernen, aber sobald Sie sie gelernt haben, ist es normalerweise besser / einfacher, sie durch gute Anleitung / Code-Reviews mit Ihrem Entwicklungsteam durchzusetzen. Auf diese Weise können Sie verwenden, was in Ihrer Umgebung funktioniert, und nicht verwenden, was in die Quere kommt.
Wenn Sie 12 Dienste haben, wie verwalten Sie die Config-Hölle, die auftreten kann? Vor allem, wenn Sie Dienste haben, die von anderen Diensten abhängig sind. Wenn all das und alle benutzerdefinierten Bindungen und Verhaltensweisen in die Konfiguration eingefügt werden, kann dies ein Albtraum sein. Wie machen Sie Ihre Dienste im Unternehmen bekannt? Wird alles über Mund-zu-Mund-Propaganda, gutes Build-Management und Source-Control gemacht?
Tags und Links wcf projects-and-solutions