Ich habe eine Schnittstelle zu einer .NET-Service-Schicht, die wiederum über einen Web-Service mit einem System eines Drittanbieters kommuniziert. Dies behandelt eine Reihe von verschiedenen Aufgaben im Zusammenhang mit der Funktionalität des Drittanbietersystems (es ist eigentlich ein maßgeschneidertes CRM-System, aber da der Kontext nicht relevant ist, werde ich dies für etwas Triviales austauschen).
Das Interface sieht ungefähr so aus:
%Vor% Jetzt funktionieren meine Modelle wie folgt: Ich habe ein BaseResponseModel , von dem jedes SomethingModel erbt. Jedes SomethingModel enthält einige grundlegende Eigenschaften und umschließt auch Something - wie folgt:
Basisantwortmodell
%Vor%Spezifische Antwortmodelle
%Vor% Hier enthalten Car und Person einfach eine Menge öffentlicher Eigenschaften. Dann nimmt jede Methode von IMyService ihre Argumente, formatiert eine Anfrage an einen .asmx-Webdienst, analysiert die Antwort in ihrem Antwortmodell und gibt sie an den Aufrufer zurück (ein .ascx-Codebehind).
Die Anzahl der verschiedenen ...Model -Klassen (ganz zu schweigen davon, dass sie alle unterschiedliche Eigenschaftsnamen für ihre umschlossenen Objekte haben) wird jedoch hässlich. Ich bin in der Absicht, etwas in der Art des Folgenden zu tun:
Meine ASP.NET-Steuerelemente erhalten dann ServiceResponse<T> von jeder Methode in IMyService .
Ist dies die "konventionell korrekte" Verwendung von Generika in C #? Oder überdeckt das einfach tiefere architektonische Mängel mit meiner Lösung? Fehlt etwas in meiner vorgeschlagenen Lösung (obwohl die Implementierungen der verschiedenen Methoden Get und Add nicht so generisch sind wie die Prototypen sie erscheinen lassen)?
Haftungsausschluss: Entschuldigung, wenn diese Frage "zu subjektiv" ist, aber es schien zu spezifisch, um eine theoretische Frage für Programmers.SE zu sein und etwas zu allgemein, um eine Frage für CodeReview.SE zu sein. Ich bin offen für Vorschläge, wie man die Frage gegebenenfalls verbessern kann.
Ich sehe kein Problem mit dieser Verwendung von Generika, es sei denn, Sie möchten, dass jemand Ihren Dienst von etwas anderem als .NET benutzt. Ich denke, es erzeugt ziemlich hässliche Vertragsnamen für die WSDL.
Für Ihren Anwendungsfall würde ich sagen, dass es in Ordnung ist. Ich bin froh, dass du auch von Model auf Response gewechselt hast. Ich würde das vorschlagen.
Je nachdem, wie die Fehler verwendet werden, würde ich persönlich lieber eine (aggregierte) Ausnahme für sie erstellen. Wenn Sie es jedoch für die Validierung von Formularen verwenden, würde ich sagen, dass das akzeptabel ist.
Wahrscheinlich ist meine Antwort auch zu sehr unterworfen - aber ich würde vorschlagen, die Erzeugung von Abhängigkeiten zu vermeiden, bevor Sie zumindest in der Beta-Version ein stabiles Arbeitssystem haben. Vor allem, wenn Sie am Anfang der Entwicklung stehen. Auch als Vererbung in einem der stärksten Relationstypen sollte es so lange wie möglich beiseite gelegt werden.
Wenn Sie eine Basisklasse oder eine generische Klasse hinzufügen, die gleich aussieht, versetzen Sie sich in sehr harte Frames.
Was ist, wenn es beispielsweise eine Situation gibt, in der Sie Wörterbücher oder Fehler finden? Oder Sie benötigen einen speziellen Antwortcode für CarRequest? Oder spezielle Antworttyp wie 'Redirect'?
Also - mein Vorschlag ist, dass Sie eine spezielle Art von Antwort pro Anfrage machen , bis Sie einige Antwort Ähnlichkeiten nach erheblicher Entwicklung herausfinden.
Es sollte GetCarResponse bis GetCar geben. Planen Sie Fehler in der Antwort? Wirf einfach eine Ausnahme. Nicht gefunden? Gibt null zurück. Gefunden? Gib zurück, was du gefunden hast, und kümmere dich nicht um Fehler.
Wahrscheinlich erfordert das ein wenig mehr Codierung, aber Sie haben Ihre Hände frei von einigen künstlichen Einschränkungen.
Tags und Links c# asp.net generics architecture design