WCF DataContract-Klasse mit Methoden

Question

Dies ist eher eine philosophische/Best-Practice-Art der Frage als ein technisches Problem.

Gibt es starke Argumente gegen das Schreiben einer DataContract-Klasse mit Methoden, die nur serverseitig verwendet werden sollen? Oder was ist mit zusätzlichen Eigenschaften, die nicht mit dem Attribut DataMember versehen sind?

Zum Beispiel:

[DataContract] 
public class LogEntry 
{ 
    [DataMember] 
    public string Message { get; set; } 
    [DataMember] 
    public string Severity { get; set; } 

    public string SomeOtherProperty { get; set; } 

    ... 

    public void WriteToDatabase() 
    { 
    ... 
    } 
} 

nicht tun es wie ein sehr viel zusätzliche Arbeit scheint, dass ich zu vermeiden bevorzugen, obwohl Methoden Erweiterung könnte es leichter machen. Aber als ein guter Entwickler frage ich mich, ob es eine schlechte Praxis ist, dies zu tun.

Answer 1

Sie können dem Typ natürlich alles hinzufügen, was Sie wollen, denn soweit WCF betrifft, sind nur Mitglieder, die sich explizit als DataMembers angemeldet haben, Teil des Vertrags und werden als solche serialisiert.

Ich denke, dass es sauberer ist nicht legen Sie fremde Mitglieder in einen Vertrag als das kann verwirrend sein, wenn Sie den Typ verwenden.

Answer 2

Eigentlich ist es hängt wirklich von dem Kontext

durch den Kontext ich meine: Erstes Projektmanagement Kontext: Geld Budget/Zeit/developpers Niveau/erwartete Lebensdauer des Projektes Dann Kontext WCF: Es ist ein Webservice (wsdl) oder eine namedpipe Übertragung

Wenn Sie alles kurz haben und Sie erwarten niemanden als die Clients, die Sie entwickeln, um eine Verbindung mit dem Webdienst herzustellen, und Sie fühlen sich mit diesem Ansatz bequem.

In allen anderen Fällen würde ich vorschlagen, den Vertragscode sauber von Implementierungsdetails zu trennen.

Beachten Sie, dass Sie in einem WCF-Namedpipe-Kontext daran interessiert sein könnten, nur einmal diesen Vertrag in einer Assembly zu implementieren, die von den Clients und dem Server gemeinsam genutzt wird. In diesem Fall riskieren Sie, Clients Signaturen des Servers auszusetzen.

Answer 3

Technisch können Sie Implementierung in der gleichen Klasse mit dem Datenvertrag hinzufügen. Nur die zugewiesenen Eigenschaften werden serialisiert.

In Ihrem Beispiel haben Sie das Objekt, Transport und wie Datenbank in der gleichen Klasse schreiben:

[DataContract] 
public class LogEntry 
{ 
    ... 

    public void WriteToDatabase() 

Ich würde empfehlen, dass Sie Ihr Front-End-Code und Objekte, die von Ihrem persistance separatem serialisiert erhalten ist . Ich würde sogar eine separate Datenbankzugriffsschicht empfehlen, die keine Kenntnis der Schichten oder Verantwortung der darüber liegenden Schichten hat, die eigene Transport- und Geschäftslogik besitzen.

Wenn sich die Datenbankpersistenz in Ihrem Datenkontrakt und der Transportschicht befindet, ist es im Laufe der Zeit nicht möglich, Schichten zu entfernen und zu ersetzen, wenn Sie dies benötigen - es handelt sich um einen Blob Code.

Die Trennung der Schichten hilft auch beim Testen. Die Möglichkeit, eine Code-Einheit ohne alle Abhängigkeiten eines vollständigen Systems zu testen, ist wertvoll. Wenn Sie z. B. die Datenbankpersistenz voneinander trennen und sogar mit einer Schnittstelle entkoppeln, können Sie zum Testen der Geschäftslogik Ihrer Einheit die Persistenz durch eine In-Memory-Implementierung ersetzen.

Ein Problem besteht darin, wie Sie diese Objekte an die DAL übergeben, wenn sie keine Kenntnis von den Objekten haben, die transportiert werden. Um die Trennung zu erzwingen, habe ich eine Datentypen-DLL gesehen, die einfach diese Strukturen mit Datenvertragsdekorationen enthält, eine Diensteschicht, die den Transport besitzt, und eine BLL/DAL, die beide die Typen dll referenzieren.

Hoffe, dass hilft.