Il modo migliore per esporre un servizio orientato ai dati

3

Al momento sono incaricato di scrivere un servizio wcf che, per ora, verrà utilizzato solo all'interno della rete aziendale, il problema è che non sono sicuro di come gestire le operazioni che espone.

Il software che utilizzerà questo servizio dovrà modificare tabelle simili in modi diversi. Ad esempio una tabella, che ha le colonne a, b, c e d. Il programma X aggiorna solo le colonne aeb, mentre il programma Y aggiorna b, c e d.

Ritengo che un metodo di aggiornamento generico che accetti l'intero record sia più facile da scrivere e rende il servizio meno gonfio. Ma si sente meno sicuro e probabilmente renderebbe più difficile la comprensione per i nuovi sviluppatori.

Come gestisco al meglio queste situazioni a livello di servizio?

modifica: Sì, le attività sono in un certo senso univoche, ma il problema è che è difficile capire quanto debba essere unico il servizio. Devo fare un servizio generale per consentire l'accesso ai dati e lasciare che i dettagli di tali attività siano gestiti lato client? I problemi di sicurezza non sono così alti. La più grande preoccupazione è la manutenibilità e la facilità di comprensione. Al momento abbiamo 20+ database in cui alcuni di essi hanno oltre 100 tabelle.

    
posta vhs 25.01.2011 - 14:59
fonte

2 risposte

3

In generale un servizio dovrebbe adottare un approccio senza stato.

Il servizio consiste nel fornire accesso ai dati o nella manipolazione dei dati, tuttavia dovrebbe, se possibile, rimanere apolidi. IBM ha una ottima spiegazione che afferma ...

Services should be independent, self-contained requests, which do not require information or state from one request to another when implemented. Services should not be dependent on the context or state of other services. When dependencies are required, they are best defined in terms of common business processes, functions, and data models, not implementation artifacts (like a session key). Of course, requester applications require persistent state between service invocations, but this should be separate from the service provider.

Forniscono anche un esempio ...

Here is an example of the wrong way to define a conversation:

  • Richiedente: "Qual è il saldo del conto corrente di Bruce?"
  • Provider: "$ x"

  • Richiedente: "E qual è il suo limite di credito?"

  • Provider: "$ y"

The provider is required to remember Bruce’s account between requests, which introduces complexity into the service implementation. Stateless service design would redefine the conversation as follows:

  • Richiedente: "Qual è il controllo di Bruce saldo del conto? "
  • Provider: "$ x"
  • Richiedente: "Qual è il merito di Bruce limitare? "
  • Provider: "$ y"

Come puoi vedere, esistono approcci esistenti per gestire un'architettura SOA. Inoltre, concentrati sulla definizione dell'interfaccia con la longevità in mente. Un'API in rapida evoluzione rende molto più difficile lo sviluppo di uno sviluppatore su un'API più difficile ma stabile.

    
risposta data 25.01.2011 - 16:09
fonte
0

Le prestazioni possono essere un problema, quindi la dimensione dei dati dei record potrebbe essere una considerazione.

Il consumatore ha bisogno dei dati? Ci sono problemi di sicurezza?

    
risposta data 25.01.2011 - 16:40
fonte

Leggi altre domande sui tag