Domanda di progettazione OO - Libreria / Oggetti per API che include riferimenti di identificazione

Question

Domanda di progettazione OO - Libreria / Oggetti per API che include riferimenti di identificazione

#1 da (1 voti)
#2 da (0 voti)

3

API pubblica:

getClients / getClientById - returns a json object like:

    { clientid: 1, name: "Client1" }

getProjects / getProjectById - returns a json object like
    { projectid: 5, name: "MyProject", clientid: 1}

Domanda : come progettare una libreria e un insieme di oggetti per interagire con questa API in modo specifico con il problema di come il progetto contiene l'ID cliente. Quello su cui continuo a scontrarmi è che l'oggetto del progetto contiene un clientid, quindi creo il mio oggetto di progetto con solo un ID o anche un oggetto client i.e

class Project
{
    int projectId ...
    string name ....

    int clientId....
    Client client // Not sure about this pattern as it wont always be initialized?
}

Come un paio di soluzioni / idee potresti:

Forza il progetto a prendere un oggetto Client nel costruttore, ma ora imponi un hit all'API prima di creare un progetto.
Non hai il membro del cliente in Project ma ora usi la libreria ma questo rende più difficile l'uso del sistema di oggetti?
Chiedere all'oggetto del progetto di prelevare il client dall'API in base alle esigenze

Preoccupazioni

Ogni volta che ti trovi in un oggetto del progetto devi fare un viaggio all'API pubblica per ottenere il nome del cliente.
Quando ti trovi in un oggetto del progetto, il riferimento del client potrebbe essere nullo (se lo includi).
Se il progetto sa come ottenere un client tramite l'API, ora il nostro codice sta diventando un pasticcio confuso.

Come gestisco fino ad ora

Mantenere il client e gli oggetti del progetto il più vicino possibile alle definizioni dell'API e nella classe API wrapper compilata in alcuni caching, quindi non sono così preoccupato di chiamarlo per ottenere il client ogni volta che ne ho bisogno. Il codice non è ancora ottimo perché finisce con l'aspetto di:

var project = apiWrapper.getProject(5)
out("This project belongs to client " + apiWrapper.getClient(project.clientId)
// note this call to getClient has cahcing in my implemtation

design api-design object-oriented-design

posta nextgenneo 16.11.2014 - 14:26

fonte

2 risposte

Leggi altre domande sui tag design api-design object-oriented-design

Processo decisionale e manutenzione Decidere il modo migliore di modellare un periodo di applicazione o un periodo di tempo per un programma

score 1 · Answer 1

Dimentica l'API per iniziare. Modella il tuo dominio aziendale, il che significa che un Progetto ha un Cliente: non un ClientId, un Cliente.

Quindi, nell'API, traduci da e verso il modello e la vista esterna (JSON). Questa è una delle responsabilità standard del livello API ("controller"). Ovviamente, questo approccio ha senso solo se stai utilizzando un ORM (ad esempio Hibernate) che automatizzerà la sincronizzazione e la persistenza del modello per te.

Per creare / aggiornare casi d'uso, il livello API o il livello di accesso ai dati, dovrebbe tradurre da ID a oggetti reali, ad es. se il Progetto JSON ha un ID cliente, cerca il Cliente con quell'ID e impostalo sul Progetto. È improbabile che lo stesso ORM lo faccia per te: il suo compito è quello di convertire tra tabelle / righe e il tuo modello a oggetti, non tra JSON e il tuo modello a oggetti. Alcuni framework di app (ad es. Spring nel mondo Java) fanno cose del genere: analizzando JSON e costruendo il modello a oggetti, usando un parser JSON adatto. Di solito, la tua libreria JSON ti consente di contrassegnare il tuo codice con annotazioni per specificare come mappare su / da JSON.

Per i casi di utilizzo delle query (ad esempio getProject), la serializzazione JSON predefinita deve includere gli oggetti di riferimento, ad es. un progetto contiene una proprietà 'client' che è un sottooggetto in formato JSON. Tuttavia, ci sono 2 motivi per deviare da questo e includere solo l'ID dell'oggetto secondario, non l'intero oggetto stesso:

Efficienza: se i tassi di richiesta sono molto alti e / o l'oggetto secondario è molto grande, e il client tipico non utilizzerà sempre il dettaglio dell'oggetto secondario
Cicli: nel caso in cui Progetto si riferisca al Cliente, ma il Cliente rinvia anche a un elenco di Progetti, si ha un ciclo. In genere, puoi "interrompere" questi cicli usando le tue annotazioni JSON (se presenti) o esponendo solo un lato della relazione nel tuo modello.

score 0 · Answer 2

Perché il Cliente non può contenere anche il proprio valore di identificazione? Quindi utilizzerai sempre l'oggetto Client (sono, dopo tutto, i dati di cui hai bisogno) pur mantenendo il riferimento all'ID da utilizzare per identificare in modo univoco quel particolare client.