Modi per mantenere lato astratto metodo server per WCF

Question

Siamo far rispettare tutti gli oggetti nostro dominio per implementare GetHashCode.

namespace Core
{
  [Serializable]
  public abstract class DomainObject
  {
    public abstract override int GetHashCode();
  }
}

namespace Entity.Domain
{
  [Serializable]
  [DataContract]
  public partial class IdCard : DomainObject
  {
    private System.Int32 _effDte;

    [DataMember]
    public virtual System.Int32 EffDte
    {
        get { return _effDte; }
        set { _effDte = value; }
    }

    public override int GetHashCode()
    {
        return EffDte.GetHashCode();
    }
  }
}

Quando si espongono questi oggetti dominio tramite WCF, il seguente servizio generato è che richiedono una modificazione post-aggiornamento per compilare.

//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//     Runtime Version:2.0.50727.3053
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

namespace IdCardManagerServiceReference {
using System.Runtime.Serialization;
using System;


[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "3.0.0.0")]
[System.Runtime.Serialization.DataContractAttribute(Name="IdCard", Namespace="http://schemas.datacontract.org/2004/07/Entity.Domain")]
[System.SerializableAttribute()]
public partial class IdCard : Core.DomainObject, System.Runtime.Serialization.IExtensibleDataObject, System.ComponentModel.INotifyPropertyChanged { 
    [System.NonSerializedAttribute()]
    private System.Runtime.Serialization.ExtensionDataObject extensionDataField;

    [System.Runtime.Serialization.OptionalFieldAttribute()]
    private int EffDteField;

    [global::System.ComponentModel.BrowsableAttribute(false)]
    public System.Runtime.Serialization.ExtensionDataObject ExtensionData {
        get {
            return this.extensionDataField;
        }
        set {
            this.extensionDataField = value;
        }
    }

    [System.Runtime.Serialization.DataMemberAttribute()]
    public int EffDte {
        get {
            return this.EffDteField;
        }
        set {
            if ((this.EffDteField.Equals(value) != true)) {
                this.EffDteField = value;
                this.RaisePropertyChanged("EffDte");
            }
        }
    }
}

Tutte le idee su come mantenere il requisito di GetHashCode, ma rimuovere il requisito per qualsiasi codice sul client (come un aggiornamento o come classi parziali)?

Answer 1

Se davvero si richiede che tutti i C # i consumatori per l'utilizzo del servizio WCF gli stessi modelli con codice originale in tatto quindi utilizzare "tipi riutilizzo in riferimento assemblee" dello strumento "Add Service Reference" caratteristica. Assicurati di rompere i vostri modelli / contratti / interfacce in un unico montaggio con nessun altro codice di implementazione in esso che serve come una "definizione" condivisa assemblaggio. Segnare questa assemblea come quella ai tipi di riutilizzo da quando la funzione "Add Service Reference" genera il codice proxy client.

Inoltre, solo un avvertimento proattivo: cose Semplificare per te di avere un solo implementazione uno "ufficiale" C # servizio al cliente per il vostro servizio. Non aggiungere i proxy di riferimento servizio ridondanti generati da Visual Studio per ogni singolo progetto che richiede la connettività con il vostro servizio.

Modifica

Parlando dalla recente esperienza personale, avendo progettato un'API modulare di servizi abilitati, mi permetta di fornire una consulenza più generale sul tema della modularità in quanto riguarda non solo i servizi WCF, ma il disegno generale.

Nel nostro sistema, abbiamo fatto quello che ho suggerito sopra nella creazione di un unico "Definizione" assemblea che contiene solo oggetti contrassegnata come [DataContract]:. Oggetti di dominio, modelli, i contratti di dati, quello che vuoi fare riferimento a loro come

In questo complesso anche un insieme di interfacce repository che definisce i metodi solo in termini di questi oggetti di dominio. Ci sono anche fortemente tipizzato struct identificatore definiti in questa assemblea che vengono utilizzati per i valori di identità attesa per ogni modello dal momento che questi modelli sono dati persistito e ciascuno ha una colonna Identity. Utilizzando le strutture che ints avvolgere in questo modo è preferibile usare int sé poiché ora otteniamo analisi semantica compilatore assistita, cioè Model1ID non è convertibile in Model2ID quanto semanticamente rappresentano due domini differenti nonostante il fatto che entrambi i domini sono rappresentabili dal tipo int .

Ciò che guida la modularità è la definizione di queste interfacce repository. La classe di implementazione del servizio WCF implementa semplicemente tutte le interfacce necessarie, allo stesso modo con la classe di servizio WCF implementazione client, il database classe di implementazione repository, la classe di implementazione di caching proxy, l'invocazione del metodo di registrazione classe di implementazione, ecc Tutto del calcestruzzo esistono classi di implementazione in altri assiemi, cioè non in "Definizione" assemblaggio che contiene le interfacce e modelli. Queste classi implementano le interfacce e sembrano il codice consumatore stesso.

La chiave è quello di mantenere il vostro codice del consumo API agnostica delle classi di implementazione specifica e fare riferimento solo le interfacce. I modelli stessi sono tenuti come semplici contenitori di dati con alcuna implementazione della logica di business trovato al loro interno. Credo che questo schema si riferisce a come anemico, ma a me "anemico" ha una connotazione negativa, quindi non mi piace usare questo termine per descrivere questo progetto.

Quello che si ottiene è il codice dei consumatori implementare la logica di business che non importa se si sta parlando con un servizio WCF o direttamente a un database, o che la cache viene attuato senza soluzione di continuità, o che le tue chiamate di metodo vengono registrati, o qualsiasi altra cosa altri usi del proxy si può trovare.

In sintesi, la progettazione di interfacce e rendere la vita più facile per te. Ma farlo solo se si è sicuri nella vostra capacità di pratica autocontrollo. Nel nostro sistema, che ho progettato, abbiamo T4 template che generano quasi tutto il codice boilerplate che arriva con servizi WCF al punto in cui tutto quello che dobbiamo fare manualmente è definire il modello, progettare l'interfaccia, e scrivere il codice di accesso al database . La facciata WCF viene fornito gratuitamente con un semplice tasto destro del mouse e "Esegui strumento personalizzato" sui modelli T4. Lo adoro. :)

Answer 2

Fissare lo spazio dei nomi sulla vostra classe parziale. Potrebbe essere necessario modificare gli attributi e l'eredità.

namespace DCS2000.IDCardExclude.UI.IdCardManagerServiceReference
{
  [Serializable]
  [DataContract]
  public partial class IdCard : DomainObject
  {
    public override int GetHashCode()
    {
        return EffDte.GetHashCode();
    }
  }
}