Progettazione dell'elaborazione dei file che gestisce molti formati di file, analisi, convalida e persistenza

Question

Se si dovesse progettare un componente/sistema di elaborazione file, che potrebbe contenere un'ampia varietà di formati di file (inclusi formati proprietari come Excel), analizzare/convalidare e memorizzare queste informazioni in un DB .. Come lo faresti?

NOTA: il 95% delle volte 1 riga di dati di input equivale a un record nel database, ma non sempre.

Attualmente sto usando un software personalizzato che ho progettato per analizzare/convalidare/archiviare i dati dei clienti nel nostro database. Il sistema identifica un file in base alla posizione nel file system (da una caduta ftp) e quindi carica un file di "definizione" XML. (L'XML corretto viene caricato in base a dove il file di input è stato rilasciato a).

L'XML specifica elementi come il layout del file (delimitato o larghezza fissa) e gli elementi specifici del campo (Lunghezza, Tipo di dati (numerico, alfa, alfanumerico) e quale colonna DB memorizzare il campo in).

  <delimiter><![CDATA[ ]]></delimiter> 
    <numberOfItems>12</numberOfItems> 
    <dataItems> 
    <item> 
    <name>Member ID</name> 
    <type>any</type> 
    <minLength>0</minLength> 
    <maxLength>0</maxLength> 
    <validate>false</validate> 
    <customValidation/> 
    <dbColumn>MembershipID</dbColumn> 
    </item> 

A causa di questo disegno i file di input devono essere il testo (larghezza fissa o delimitati) e hanno un rapporto 1 a 1 dal campo di dati del file di input per colonna DB.

Mi piacerebbe estendere le capacità del nostro sistema di elaborazione file in modo da includere Excel o altri formati di file.

Ci sono almeno una mezza dozzina di modi in cui posso procedere, ma sono bloccato in questo momento perché non ho nessuno con cui rimbalzare le idee.

Ancora: se dovessi progettare un componente di elaborazione file, che potrebbe contenere un'ampia varietà di formati di file (inclusi formati proprietari come Excel), analizzare/convalidare e archiviare queste informazioni in un DB .. Come vorresti fallo?

Answer 1

Si consiglia di avviare un blog, quindi se si è su qualcosa come LinkedIn è possibile indirizzare la discussione sul proprio blog o avviare una discussione su LinkedIn, poiché alcune discussioni proseguono per un po '.

Answer 2

SO è buono per le specifiche, sembra che la discussione vera non è così facilmente fatto qui. I commenti sono troppo piccoli per lo scambio di idee. Tenderei ad andare altrove.

Anche se tali discussioni dovrebbero essere indipendenti dalla tecnologia, sospetto che probabilmente scoprirete che i campi Java e .Net non si incontrano troppo. Guarderei The Server Side ma faccio Java e quindi cerco Java.

Answer 3

Beh, un design semplice è qualcosa di simile ...

+-----------+ 
| reader1 | 
|   |--- 
+-----------+ \--- 
        \--- +----------------+    +-------------+ 
         \--| validation |    | DB   | 
         /---|    |---------------|    | 
+-----------+ /----- +----------------+    +-------------+ 
| reader2 |---- 
|   | 
+-----------+ 

lettori prendersi cura di convalida di file (esiste più i dati?) E l'analisi, la sezione di convalida si occupa di ogni logica di business, e la DB ... è un DB.

Quindi parte di ciò che dovresti progettare è il contenitore dati ReaderToValidator generico. Questo è più di un tipo di contenitore di logica aziendale. Sospetto che tu voglia lo stesso tipo di dati indipendentemente dal formato di input, quindi G.R.2.V. non sarà troppo difficile

È possibile eseguire questa operazione in modo polimorfico progettando una superclasse GR2V con il metodo Validator e i membri dati, quindi ogni sottoclasse di Reader fuori da GR2V e riempie i dati con il proprio metodo ReadParseFile. Ciò introdurrà un po 'più di accoppiamento, piuttosto che un approccio procedurale rigoroso. Sarei procedurale per questo, dal momento che i dati vengono elaborati proceduralmente nella progettazione concettuale.