I dati statici e storici dovrebbero essere divisi nell'API? Fino a che punto?

Question

I dati statici e storici dovrebbero essere divisi nell'API? Fino a che punto?

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

1

Il progetto è un'interfaccia di sola lettura per un database aziendale.

Nel database, ci sono alcuni dati "statici" sui reparti, in una tabella Departments . Il valore di questi campi non cambia nel tempo (ad esempio DepartmentID , DepartmentName , DepartmentDescription , HistoryTableName , ecc.).

Ci sono anche alcuni dati con data e ora. I dati storici per ciascun dipartimento sono memorizzati in una tabella dedicata (denominata HistoryTableName , con campi come timestamp , numberOfEmployees , Energy Consumption , ...). Come puoi immaginare, il layout dei dati non è qualcosa che può essere modificato in questo ambito.

Il punto dell'interfaccia deve essere in grado di accedere ai dati per tutti i reparti, in qualsiasi momento.

Ho trovato la parte "statica": esiste un controller company , che restituisce un oggetto con una proprietà departments , con i relativi ID, descrizioni, ecc.

Tuttavia sono confuso su come gestire i dati storici:

Dovrebbe essere una parte dei dati "statici"? Modificherei la classe department con le proprietà per i dati storici. (E quindi, vorrei restituire l'intera configurazione ogni volta che vengono richiesti nuovi dati).
Shoud Creo un flusso parallelo (nuovo controller companyHistory , nuova classe, ecc. che restituisce solo l'ID dei reparti e la loro cronologia e l'associazione è eseguita nell'interfaccia utente?)
...

Ho pochi dubbi sul fatto che questo sia stato studiato prima, e che ci sia un modello ben noto per gestire tali casi, ma non sono stato in grado di trovare alcun riferimento ad esso.

Potresti indicarmi un modello simile?

architecture design-patterns data-structures

posta Maxime 08.07.2018 - 18:54

fonte

2 risposte

1

Se la tua API è rivolta al cliente, la sua progettazione dovrebbe essere guidata dai requisiti del prodotto, non dal modello di dati. Le tue particolari esigenze potrebbero non richiedere affatto l'accesso ai dati storici (quanto sarebbe utile conoscere la cronologia del nome di un dipartimento?)

Se dovesse essere esposto, immagino che gli attuali record del dipartimento sarebbero necessari molto, molto più di quelli storici, quindi probabilmente vorrai mantenere quelli leggeri e non caricarli con il portare in giro la loro storia ogni tempo in cui un dipartimento viene recuperato.

risposta data 09.07.2018 - 01:18

fonte

Leggi altre domande sui tag architecture design-patterns data-structures

DDD: come e dove cambiare la password per l'entità utente? Progettazione del sistema per l'utilizzo del calcolo del credito

score 0 · Accepted Answer

Come primo passo, metterei in discussione l'staticità delle informazioni del dipartimento. Strutture organizzative veramente immutabili probabilmente non esistono in aziende che vivono da tempo. Per quanto riguarda la tua domanda reale, non so a priori che conosco uno schema specifico. La soluzione più utile potrebbe essere un'API che accetta un parametro timestamp facoltativo per mostrare i dati (e possibilmente la struttura organizzativa) per quel punto nel tempo, o i dati correnti se il parametro non viene fornito. Non lasciare che i dettagli di quale parte dei dati sia statica insinuarsi nel codice client, rende le cose complicate e fragili.