Definizione di un endpoint del servizio Web tramite configurazione anziché codice

2

Sono interessato alla creazione di un endpoint del servizio Web in C # /. NET completamente configurabile. Per semplificare l'ipotesi, non esiste alcun requisito GET / query / recupero. Ho solo bisogno di una guida su come iniziare qui.

L'obiettivo è di avere una soluzione di base costruita, testata e distribuita che possa essere configurata per nuovi oggetti, evitando così il requisito di modificare, costruire e distribuire l'intera soluzione ogni volta che un oggetto viene aggiunto / rimosso / modificato. Questa configurazione dovrebbe supportare il controllo delle versioni in base all'ambiente in cui opererà.

Supponiamo di avere un file di configurazione come il seguente:

{
  "V1": {
    "Person": [
      {
        "Name": "FirstName",
        "Required": true,
        "Type": "string",
        "MaxLength": 25
      },
      {
        "Name": "Lastname",
        "Required": true,
        "Type": "string",
        "MaxLength": 25
      },
      {
        "Name": "Title",
        "Required": false,
        "Type": "string",
        "MaxLength": 50
      }
    ]
  },
  "V2": {
    "Person": [
      {
        "Name": "FirstName",
        "Required": true,
        "Type": "string",
        "MaxLength": 25
      },
      {
        "Name": "Lastname",
        "Required": true,
        "Type": "string",
        "MaxLength": 25
      },
      {
        "Name": "Title",
        "Required": false,
        "Type": "string",
        "MaxLength": 50
      },
      {
        "Name": "DateOfBirth",
        "Required": false,
        "Type": "DateTime"
      }
    ]
  }
}

Con questa configurazione voglio un'applicazione che esponga un endpoint per un chiamante per inviare un oggetto e convalidare l'oggetto rispetto alle regole di tipo. Dovrebbe anche esporre un WSDL.

Per essere chiari, non voglio scrivere un semplice singolo endpoint generico che possa prendere una serie di attributi chiave-valore e quindi convalidare - Voglio generare un contratto.

In sostanza, sto cercando di avere un servizio web a contratto senza dover creare POCO. Ciò consentirà ai mittenti di prendere in giro più facilmente l'endpoint per il loro lavoro di sviluppo.

Per i curiosi, i dati in arrivo verranno inviati a un bus di messaggistica per essere elaborati da altri servizi. Pertanto, l'endpoint deve eseguire la valutazione di tipo / lunghezza / ecc. Ma non voglio creare / aggiornare i POCO e i controller insieme a tutti i test e i mal di testa di un'implementazione aziendale semplicemente perché alcuni oggetti hanno un nuovo campo. / p>     

posta Nicknow 24.01.2017 - 19:27
fonte

2 risposte

0

Il modo tradizionale per farlo è definire i tipi in un file XSD e definire il contratto di servizio in un file WSDL che fa riferimento ai file XSD. Stai facendo praticamente la stessa cosa in un formato JSON su misura, che va bene se vuoi fare il lavoro, ma non troverai che ci siano molti strumenti là fuori per aiutarti.

Un problema che scoprirai rapidamente è che, anche se è abbastanza semplice definire un'interfaccia dalla configurazione o dal markup, non ti porterà molto lontano, perché avrai ancora bisogno del codice per gestire chiamate di servizio. Dato che dici di non voler lavorare con coppie tag / valore, significa che il tuo codice dovrà essere strongmente digitato, il che significa che una soluzione generalizzata non è possibile.

Suppongo che potresti creare qualcosa che genererà dinamicamente il codice per tradurre dal messaggio di servizio strongmente tipizzato a una struttura di dati di formato generale c #. Il che suona molto simile al tipo di soluzione di tag / valore che stavi evitando. Quindi non stai veramente risolvendo un problema, ma spostalo, anche se lo sposterai dall'interfaccia pubblica al codice privato.

    
risposta data 27.03.2017 - 22:13
fonte
0

Non sono sicuro di aver capito completamente, ma ho implementato con successo un servizio generale per qualsiasi contratto che utilizza il routing WCF 4 per eseguire, registrare e riprodurre i messaggi SOAP. Il tuo uso può o non può essere nella stessa vena ma prova questi link (so che i link non dovrebbero essere postati come risposta ma gli articoli sono troppo grandi per riassumere)

Documentazione corrente Microsoft

Anche Michele Bustamante ha scritto alcuni articoli. Non sono sicuro se questi sono ciò che ho usato - non riesco a trovare gli originali ma questi sembrano coprirlo:

Parte 1

Parte 2

Un altro esempio

La chiave per questo è

namespace WcfRouterService
{
    [ServiceContract]
    public interface IRouter
    {
        [OperationContract(Action = "*", ReplyAction = "*")]
        Message Action(Message msg);
    }



public Message Action(Message msg)
        {
            try
            {                    
                return ProcessMessage(msg);
            }
            catch (Exception e)
            {
                System.Diagnostics.Trace.WriteLine(e.ToString());
                throw;
            }
        }
}

Non sono sicuro che sia d'aiuto o meno e non ho usato JSON.

    
risposta data 28.03.2017 - 07:55
fonte

Leggi altre domande sui tag