Progettazione dell'accesso al "database" basato su file

La chiave qui è disporre di livelli con interfacce ben definite. Lo strato più basso si occupa strettamente dell'accesso fisico ai file. Gestisce cose come il caching, l'accesso simultaneo, l'apertura, il flushing, ecc. La sua interfaccia consente ai livelli superiori di recuperare una riga alla volta senza doversi preoccupare di cose come se il file fosse già aperto.

Il secondo livello fornisce strutture di dati stupide con cui lavorare. La sua interfaccia consisterebbe fondamentalmente in un mucchio di record con colonne di tipi di dati semplici, che sono tutti contenuti in un singolo file. Righe del database, se vuoi.

Il terzo livello fornisce oggetti intelligenti con cui lavorare. Raggruppa le righe del database da più tabelle per creare oggetti con interfacce amichevoli.

I call the Structure a "Thick object". An alternative ("thin objects") is to stick to objects that are fully represented in a file, even if poor in high-level domain meaning

Questi non sono esclusivi. Spesso devi fare entrambe le cose.

I problemi relativi al formato fisico e al layout logico sono separati dal dominio problematico. Tre strati.

objects are able to deserialize themselves from file ("pickle-like" in python parlance),

Non funziona bene a lungo termine. La definizione della classe diventa ingombra di problemi di rappresentazione.

Gli oggetti Python non si picchiano. Il decapaggio viene gestito separatamente. A volte una classe deve fornire suggerimenti per il codec all'algoritmo pickle.

dumb data containers filled by stateless parser objects (one per file), or even by the database object itself.

Gli oggetti parser "stateless" non sempre funzionano bene.

I progetti di parser (o di fabbrica o di costruttore) funzionano bene. Basta lasciare "senza stato". Pensa alla scansione lessicale e all'analisi in modo separato rispetto alle rappresentazioni del dominio del problema fisico, logico e finale che potrebbero essere richieste.

How should I perform proper deserialization in this case of "raw mapping"?

Potrebbero essere necessarie classi di formato fisico. Spesso, questi sono già forniti in una libreria di lingue. Non reinventare la ruota.

Thin or thick objects ?

Non è una scelta esclusiva. Hai una disposizione logica e le classi di livello dominio appropriate indipendentemente da qualsiasi rappresentazione fisica.

Smart or dumb ?

Al di fuori del dominio del problema, le classi dovrebbero essere focalizzate sulla rappresentazione. Non lo so, questo li rende stupidi o no.

Mantenere le preoccupazioni separate.

• Il formato fisico è per CSV, ZIP, XML, JSON, ecc.

• Il layout logico gestisce le variazioni nei nomi delle colonne, i tipi di dati e la struttura.

• Il dominio dei problemi è il vero oggetto con cui vuoi lavorare.

Lo faccio serializzando e deserializzando oggetti usando XML. Ciò ti consente di definire le tue regole in base alla struttura delle tue classi.

Alcuni semplici metodi di supporto ToXml() e FromXML() fanno tutto il lavoro pesante.

Quindi, ad esempio:

public class MyRecord
{
    [XmlAttribute]
    public string Foo { get; set; }

    [XmlAttribute]
    public int Bar { get; set }

    [XmlAttribute]
    public double Baz { get; set; }
}

genera un XML che assomiglia più o meno a questo:

<MyRecord Foo="ABC" Bar="123" Baz="123.45">

Puoi renderlo elaborato come vuoi, usando la composizione per nidificare gli oggetti all'interno di altri oggetti, e così via, creando strutture ad albero o anche collezioni.

public class MyRecordTree
{
    public MyRecordTree Node { get; set; }
    public List<MyRecordTree> Children { get; set; }
}