WCF Mehrere Verträge mit doppelten Methodennamen
Ich habe einen Dienst mit mehreren Verträgen so gerne.
[ServiceContract]
public partial interface IBusinessFunctionDAO {
[OperationContract]
BusinessFunction GetBusinessFunction(Int32 businessFunctionRefID);
[OperationContract]
IEnumerable<Project> GetProjects(Int32 businessFunctionRefID);
}
[ServiceContract]
public partial interface IBusinessUnitDAO {
[OperationContract]
BusinessUnit GetBusinessUnit(Int32 businessUnitRefID);
[OperationContract]
IEnumerable<Project> GetProjects(Int32 businessUnitRefID);
}Ich dann explizit implementiert, die jeweils eine der Schnittstellen so gerne.
public class TrackingTool : IBusinessFunctionDAO, IBusinessUnitDAO {
BusinessFunction IBusinessFunctionDAO.GetBusinessFunction(Int32 businessFunctionRefID) {
//implementation
}
IEnumerable<Project> IBusinessFunctionDAO.GetProjects(Int32 businessFunctionRefID) {
//implementation
}
BusinessUnit IBusinessUnitDAO.GetBusinessUnit(Int32 businessUnitRefID) {
//implementation
}
IEnumerable<Project> IBusinessUnitDAO.GetProjects(Int32 businessUnitRefID) {
//implementation
}
}Wie Sie sehen können, habe ich zwei GetProjects(int) - Methoden, aber jeder ist explizit umgesetzt werden, damit diese kompiliert einwandfrei und ist vollkommen gültig. Das problem entsteht, wenn ich wirklich beginnen, dieses als Dienstleistung an. Es gibt mir eine Fehlermeldung bleiben, dass TrackingTool enthält bereits eine definition GetProject. Während es wahr ist, ist es ein Teil von einem anderen service-Vertrag. Tut WCF nicht unterscheiden zwischen service-Verträge, die beim generieren der Methode Namen ?
Gibt es einen Weg, um es zu unterscheiden zwischen dem service-Verträge ?
Meine App.Config sieht wie folgt aus
<service name="TrackingTool">
<endpoint address="BusinessUnit" contract="IBusinessUnitDAO" />
<endpoint address="BusinessFunction" contract="IBusinessFunctionDAO" />
</service>Jede mögliche Hilfe würde geschätzt.
Dank, Raul
Ah, ich denke, ich muss Lesen Sie, wie die WSDL-tatsächlich erstellt wird. Ich dachte, dass jeder Vertrag hat seinen eigenen Namensraum innerhalb der WSDL.
...eigentlich finde ich das ziemlich verwirrend, auch. @marc_s: die WSDL-weiß über die verschiedenen Schnittstellen. Sie ausgesetzt sind, als dedizierte ports mit speziellen Bindungen.
Überprüfen Sie meine Antwort, die ich nur beantwortet, warum dies geschieht, obwohl die Schnittstellen ausgesetzt sind als dedizierte ports.
InformationsquelleAutor HaxElit | 2010-03-09
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ich denke, dass ich den Grund dafür gefunden. In der WSDL wird die Funktion automatisch ausgesetzt, wie die folgenden:
Dann in die xsd definiert die tns: namespace haben wir die folgenden:
Also der Grund für die Kollision, obwohl der service, ist das zwei verschiedene Verträge, da alle von der wsdl-Teil-Elemente sind im gleichen Namensraum. Also, wenn Sie erstellen Sie zwei Funktions-Namen, die identisch sind, erhalten Sie doppelte Elemente mit dem gleichen Namen, die das problem verursacht. Also die Lösung des Problems ist das hinzufügen von namespace-Attribut zu jedem service-Vertrag. Wenn wir unser original-service-Vertrag und ändern Sie es wie so.
Wenn wir generieren der WSDL-wir bekommen eine WSDL für jeden namespace, die wir schaffen. Dieser namespace enthält jeder port identifiziert mit all Ihren Aktivitäten und Elemente. Also in unserem separaten WSDL-s, erhalten wir die folgende:
wie Sie sehen können, Sie haben beide den gleichen element-Namen, sondern weil Sie sind in verschiedenen namespaces, die die Elemente nicht mehr miteinander in Konflikt geraten. Wenn wir einen Blick auf die xsd-Sie haben nun die gleichen Elemente definiert, aber mit anderen Parametern:
Also die Antwort auf meine ursprüngliche Frage zu machen, ist jeder service-Vertrag wohnen in einem eigenen Namensraum, so dass Sie nicht haben widersprüchliche port-Elemente. Dies gibt Ihnen auch die Flexibilität, Ihre Verträge in separaten WSDL-s, die einfacher zu verwalten, wenn Sie verteilen die Teile von Ihnen.
Nice one! Vielen Dank für das teilen im detail!
InformationsquelleAutor HaxElit
Könnten Sie versuchen, mit einem alias-vielleicht:
[OperationContract(Name = "YourMethodNameHere")]
IEnumerable GetProjects(Int32 businessUnitRefID);
Finden Sie unter: http://jeffbarnes.net/blog/post/2006/09/21/Overloading-Methods-in-WCF.aspx
InformationsquelleAutor mint
Versuchen Sie, die Aktion - Eigenschaft auf den OperationContract-Attribut für die zwei Methoden, die denselben Namen zu entfernen der Konflikt, wie so:
InformationsquelleAutor lee-m