Best practice per la memorizzazione di centinaia di piccoli oggetti con comportamento

Question

Best practice per la memorizzazione di centinaia di piccoli oggetti con comportamento

#1 da (3 voti)
#2 da (3 voti)

3

Problema : 3000 oggetti di business, ciascuno con alcuni dati regolari (~ 20-30 campi poco profondi, JSON) e un proprio piccolo comportamento unico (spesso solo una funzione javascript di una riga).

Possibili soluzioni a mio parere:

Soluzione 0 : dati business_objects.js (~ 1 MB) e funzioni sullo stesso oggetto.
Soluzione 1 : data.json (~ 800KB) + solo_behavior.js (30-40KB), unita dall'ID condiviso
Soluzione 2 : data.json (~ 800KB) + behavior_annotated.js (~ 200KB), unita dall'ID condiviso, ma ha anche alcune informazioni leggibili dall'uomo (denormalizzate / duplicate) per facilitare la comprensione
Soluzione 3 : DB (mongo / postgre) e memorizza le funzioni come stringa, quindi ripristinane con il nuovo costruttore di funzioni.
Soluzione 4 : ogni funzione in un file separato (significa cartella con più di 3000 file).
Soluzione 5 : suddivisione arbitraria di 3000 oggetti in gerarchia con coefficiente di ramificazione di 10 (10 file con 300 oggetti in ciascuno o 10 cartelle, ciascuno con 10 file, ciascuno con 30 oggetti).
Soluzione 6 : scrivi DSL basato su JSON / stringa per definizioni dichiarative di comportamento.

Vincolo extra: gli oggetti aziendali possono cambiare in base alla "forza della natura" e dobbiamo aggiornare rapidamente il nostro repository, quando ciò accade.

Tutte le soluzioni mi sembrano abbastanza brutte.

Forse qualcuno può suggerire un buon modello per affrontare tale problema?

architecture object-oriented-design architectural-patterns

posta c69 17.05.2017 - 00:06

fonte

2 risposte

3

Le soluzioni da 0 a 6 sono brutte perché sono state striate di qualsiasi significato. Questo è ciò che porta a "tutto in una scatola". Quello che manca qui è una struttura organizzativa.

Se giocassero a carte avresti semi e truppe per organizzarle. Se fossero magiche le carte di raccolta avrebbero colore e impostato per organizzarle.

Qualunque siano le tue 3000 carte, è meglio usare una soluzione che permetta loro di essere organizzate in modo da permettere alle persone di trovare la carta che stanno cercando.

Questi sono oggetti business. Quindi devono rappresentare bene il dominio aziendale.

Quindi no, tutto in una scatola e mix non è una buona soluzione. Utilizzare una soluzione che consenta una certa struttura.

risposta data 17.05.2017 - 04:41

fonte

Leggi altre domande sui tag architecture object-oriented-design architectural-patterns

Esistono degli standard per etichettare i messaggi stdout / stderr? Come cercare su e giù un grafico dal punto centrale?

score 3 · Accepted Answer

In primo luogo, dovresti riflettere su quale forma hai finalmente bisogno delle carte / oggetti business nel tuo programma per fare qualcosa di significativo con esso. Da quello che hai scritto, suppongo che se tu possiedi tutti quegli oggetti sotto forma di codice / oggetti Javascript, puoi effettivamente mischiare o distribuire le carte così come eseguire il codice quando un giocatore decide di usare una delle sue carte. Nota, per questi casi d'uso, non hai bisogno di alcuna gerarchia , la gerarchia è qualcosa che ti serve solo per mantenere i tipi di carte e le loro "regole aziendali".

Se non hai un team completo composto da cinque a dieci persone che implementano (e gestiscono) il codice per questi 3000 oggetti, hai bisogno sicuramente di un approccio dichiarativo per descrivere / implementare la maggior parte di essi. E sono abbastanza sicuro in 3000 oggetti, ci saranno tutti i tipi di ripetizioni / similitudini nel comportamento. Ad esempio, posso immaginare il tuo esempio

"when you summon minion deal 1dmg to random enemy"

potrebbe verificarsi spesso nel modulo

"when you summon <X> deal <Y> to enemies of type <Z>"

Quindi potresti provare a farne uso e creare un oggetto generatore , basato su alcuni input tabulari e alcune regole, e provare se puoi generare la maggior parte degli oggetti, incluso il codice Javascript per il comportamento, basato su modelli di codice con segnaposti. Ovviamente, ci saranno alcuni oggetti con regole troppo complesse per il tuo generatore, quindi dovrai implementarli manualmente, ma dovresti mirare che si tratti solo di una piccola parte dell'intero insieme di oggetti.

Quindi ciò che è necessario salvare è

l'input tabulare per il tuo generatore
l'implementazione per gli oggetti (si spera pochi) che non possono essere generati

I dati di input per il tuo generatore potrebbero essere memorizzati in un foglio di calcolo, testo "simile a DSL", file XML o JSON o in un database (leggero), a seconda di cosa ti senti più a tuo agio. Se c'è una sola persona alla volta che mantiene le regole, probabilmente farei un foglio di calcolo, per molte persone probabilmente proverei un database. In entrambi i casi potrebbe essere necessario fornire "stringhe di template" o campi con frammenti di codice nella tabella. Chiamalo "generatore DSL", se vuoi. 3000 righe in un foglio di calcolo sono abbastanza gestibili da una sola persona, soprattutto quando è possibile utilizzare le funzionalità di filtro e ordinamento. "nome", "colore", "rarità", "espansione", "tipo di nemico" o "tipo di regola aziendale" - con un programma di fogli di calcolo è possibile filtrare o ordinare le carte "ad hoc" in base a questi attributi, senza avere la necessità di investire troppo in anticipo il pensiero nelle gerarchie di cui potresti aver bisogno.

I restanti oggetti "non generabili" potrebbero essere implementati in normali file di testo, direttamente in Javascript. Oppure, è possibile generare anche quegli oggetti, ma fornire un "gancio" in cui è possibile aggiungere codice scritto manualmente. La tecnica per organizzare questo codice aggiuntivo (un file per tutti, un file per oggetto, qualunque cosa) dipende in gran parte da quanti di questi saranno finalmente disponibili.