wrapper API REST - progettazione della classe per le risposte agli oggetti 'lite'

Naviga le tue risposte
2

Sto scrivendo una libreria di classi per fungere da wrapper .NET gestito su un'API REST. Sono molto nuovo per OOP, e questo compito è un'opportunità ideale per me per imparare alcuni concetti di OOP in una situazione di vita reale che per me ha senso.

Alcune delle risorse / oggetti principali restituiti dall'API vengono restituiti con diversi livelli di dettaglio a seconda che la richiesta riguardi una singola istanza, un elenco o parte di una risposta "cerca tutte le risorse". Questo è ovviamente un buon progetto per l'API REST stesso, in modo che non vengano restituiti oggetti completi (aumentando così la dimensione della risposta e quindi il tempo necessario per rispondere) a meno che non siano necessari.

Quindi, per essere chiari:

  • ... / car / 1234.json restituisce l'intero oggetto Car per 1234, tutte le sue proprietà come colore, marca, modello, anno, dimensione_motore, ecc. Chiamiamo questo completo .
  • ... / cars.json restituisce un elenco di oggetti Car, ma solo con un sottoinsieme delle proprietà restituite da ... / car / 1234.json. Chiamiamo questo lite .
  • ... search.json restituisce, tra le altre cose, un elenco di oggetti auto, ma con proprietà minime (solo ID, marca e modello). Chiamiamo questo lite-lite .

Voglio sapere quali sono i pro e i contro di ciascuno dei seguenti possibili design e se esiste un design migliore che non ho trattato:

  1. Crea una classe Car che modellino le proprietà lite-lite , quindi verifica che ciascuna delle risposte più dettagliate erediti ed estenda questa classe.
  2. Crea classi separate CarFull, CarLite e CarLiteLite corrispondenti a ciascuna delle risposte.
  3. Crea una singola classe Car che contiene proprietà (nullable?) per la risposta completa e crea costruttori per ciascuna delle risposte che la popolano nella misura del possibile (e forse include una proprietà che restituisce il tipo di risposta da cui è stata creata l'istanza).

Mi aspetto che tra le altre cose ci saranno casi d'uso per i consumatori del wrapper dove vorranno iterare attraverso gli elenchi di Cars, indipendentemente dal tipo di risposta da cui sono stati creati, in modo che i tre tipi di risposta possano contribuire allo stesso lista.

Felice di essere puntato su buone risorse per questo genere di cose, e / o persino di aver detto il nome del concetto che sto descrivendo, in modo da poter indirizzare meglio la mia ricerca.

    
posta sasfrog 10.11.2012 - 05:14
fonte

2 risposte

1

In base alla tua descrizione, utilizzerei l'opzione tre. L'opzione due è probabilmente la peggiore, dal momento che si massimizzerebbe la duplicazione e si ridurrebbe il riutilizzo.

L'opzione uno è il modello di ereditarietà. Non mi sembra che si adatti bene alla situazione. La conseguente gerarchia di classi introdurrà complessità, ma non si otterrà molto nel trade-off. L'ereditarietà può essere molto utile quando si ha un numero di oggetti diversi che condividono tutti una superclasse comune. In questo caso hai davvero solo un tipo di oggetto (una macchina), hai solo diversi livelli di completezza.

Con la tua classe di auto singola dall'opzione tre, ci sono alcuni trucchi che puoi usare come il pigro caricamento delle proprietà. Fondamentalmente se la tua classe è stata riempita con la minor quantità possibile di dati allora nel getter delle altre proprietà puoi attivare una chiamata verso l'API più dettagliata e compilare il resto delle informazioni. Fai attenzione a modellare questo tipo di comportamento attorno ai modelli di utilizzo reali che l'oggetto può vedere, ma può essere di grande aiuto con la facilità d'uso per altri programmatori che consumano il tuo oggetto.

    
risposta data 10.11.2012 - 23:52
fonte
1

In C #, puoi aggiungere attributi alle proprietà di un oggetto:

Sarebbe facile creare un attributo che definisca il livello di dettaglio rappresentato da una proprietà, lite o completa, e aggiungere l'attributo a ciascuna proprietà dell'oggetto auto. Dopo aver decorato tutte le proprietà con gli attributi, scrivi una classe serializzatore che può essere alimentata da un oggetto e un livello di dettaglio come argomenti. Sarà:

  • Usa la riflessione per trovare un elenco di tutte le proprietà relative al livello di dettaglio corrente;
  • Sputa un elenco di quelle proprietà e dei loro valori attuali.

Questo ti dà:

  • Una singola classe invece di più classi;
  • La possibilità di avere un oggetto completamente popolato e di produrre una rappresentazione lite senza dover creare una copia abbreviata intermedia;
  • Una classe che può essere estesa con nuove proprietà e averle automaticamente aggiunte all'API REST.
risposta data 11.11.2012 - 01:38
fonte

Leggi altre domande sui tag

Devo utilizzare la struttura da un kit di strumenti grafici della libreria principale nel mio dominio? Gli elementi restituiti dalla query Linq-to-Entities sono trasmessi dal DB uno alla volta o vengono recuperati tutti contemporaneamente?