Definisci i campi solo una volta

Question

Definisci i campi solo una volta

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

1

Sto cercando un metodo per descrivere i campi in modo strutturato, quindi sono in grado di riutilizzarlo in vari linguaggi e livelli della mia applicazione.

Ad esempio, se sto sviluppando un'applicazione Android su prodotti alimentari, potrei avere a che fare con campi come Nome, Descrizione, Prezzo e Kcal. Tuttavia, questi campi appariranno più volte: nel viewholder della mia applicazione Android, nel server C ++ che gestisce i messaggi, nel mio database SQL che li memorizza, ecc. Imo, questo viola il principio DRY e se voglio anche Ad esempio, salvo il codice a barre di un prodotto alimentare, devo aggiungerlo a tutti questi posti.

Ho pensato di utilizzare XML o TDL, ma non sono sicuro che tali lingue siano destinate a questo obiettivo. Preferibilmente, avrei un file come questo:

Fieldname   Type        Lower bound Upper bound May be NULL
-----------------------------------------------------------
Name        string      3           100         No
Price       float       0           *           Yes    
...

Naturalmente potrei creare una cosa del genere da solo, ma sarebbe un buon modo per andare? O c'è qualcosa là fuori che viene utilizzato per questo scopo (voglio evitare errori dei principianti). Preferibilmente, avrei queste definizioni state lette in fase di compilazione perché la definizione non verrà comunque modificata in fase di esecuzione.

design-principles

posta Stefan Broeder 16.10.2014 - 08:37

fonte

2 risposte

Leggi altre domande sui tag design-principles

Programmi di Cobol e versioni di quadricromie DDD: visualizzazione alternativa del modello?

score 1 · Answer 1

Esistono già strutture come questa, ad esempio le ORM . Ciò garantirà che non sia necessario definire anche la struttura SQL. Sono più familiare con quelli Java, come DataNucleus o Hibernate.

Sulla base delle stesse annotazioni di codice, puoi generare il modello di dominio per l'applicazione Android.

Ma, secondo la mia esperienza, il mantenimento di tale framework diventerà presto molto costoso, poiché molto probabilmente avrete bisogno di molte eccezioni, come diversi vincoli (URL, tutto in minuscolo, elenco ecc.).

Se si utilizza Java sul lato server, è possibile utilizzare effettivamente le stesse classi per il modello di dominio su client e server. Ma potrebbe anche esserci un modello più sottile sul lato client (l'app per Android) che sul lato server (server Java o C ++).

score 0 · Answer 2

Alcuni pensieri:

Il problema con i campi è che si tratta di un'astrazione del codice piuttosto che un'astrazione del dominio aziendale.
Trattare name , price , kcal , ecc. come tipi anziché campi [ad es. utilizzando typedef in C ++ e le classi wrapper per le primitive in Java] si concentra su dettagli di implementazione comuni e black box come le differenze tra la rappresentazione di stringhe in Java e C ++ e le rispettive nature immutabili / mutevoli.
Gli aspetti del sistema che si riducono a typechecking come i requisiti di convalida (lungo le linee di name.length compreso tra 3 e 50) possono vivere sui propri livelli dietro le API.

In modo implicito, la direzione verso cui stai andando è verso una lingua specifica del dominio. Pensare ai tipi e al controllo dei tipi è una base su cui si potrebbe costruire.