Come progettare validazioni configurabili per importare file Excel?

Il "pattern" che stai richiedendo è chiamato Domain Specific Language (DSL) . Progettare il proprio "linguaggio" per questo tipo di problema e un interprete può essere più semplice di quanto possa sembrare a prima vista.

Il tuo linguaggio delle regole potrebbe essere solo un elenco di comandi testuali, memorizzati anche in un foglio Excel, dove ogni riga rappresenta una regola e il foglio ha alcune colonne come Active , Range , Rule type ,% % co_de.

• Parameters è semplicemente una colonna per controllare se la regola è attivata o disattivata
• Active dovrebbe descrivere a quale parte del file di input si applica la regola. Inventa una descrizione per gli intervalli che devi supportare, come una colonna specifica, un insieme specifico di righe, tutte le celle nella tabella, tutte le celle nella tabella tranne una riga di intestazione, qualsiasi cosa tu abbia bisogno per il tuo caso d'uso
• Range deve contenere una parola chiave per il tipo di regola come RuleType , NotEmpty , MaxLength , MinLength , DateFormat
• IsEmptyIfOtherColumnIsNotEmpty contiene i parametri aggiuntivi come la lunghezza minima / massima consentita o una stringa di formato per la data o i nomi delle colonne dipendenti.

Se ci provi, potresti rimanere stupito di quanto lontano ti possa arrivare. Ho implementato qualcosa di simile con successo almeno due volte, una volta per un linguaggio di elaborazione e una volta per un linguaggio di convalida.

Dato che questo dovrebbe sostanzialmente rispondere alle tue domande 1,2 e 4, una parola in più su 3: non ottimizzare in modo prematuro senza bisogno e senza misurazione. Certo, puoi provarlo, ma perché? Il tuo programma dovrà comunque leggere ogni file Excel in ordine sequenziale e registrerà il risultato della convalida da qualche parte. Questi sono processi associati I / O che non possono essere parallelizzati. Quindi l'elaborazione di più righe in parallelo potrebbe portare benefici solo se l'elaborazione della regola stessa sarà il collo di bottiglia e si rivelerà molto più lenta di I / O e se sono disponibili core CPU inutilizzati. Quindi misura prima questo, poi pensa a questa ottimizzazione, non viceversa.

Questa risposta non è intesa a togliere nulla dalla risposta di Doc Brown, ma a fungere da guida nel tuo viaggio.

Stai molto attento a creare la tua DSL o persino a fare qualcosa di configurabile. Non è che non dovresti mai neanche fare, ma devi essere consapevole di quale percorso stai percorrendo.

Questo articolo lo spiega molto bene, ma fornirò una rapida panoramica:

link

La linea di fondo è che stai per creare una lingua che permetta agli altri di gestire le regole. Dove conserverai quelle regole? Forse in un database? Cosa succede se commettono un errore e devono tornare indietro? Gestirlo meglio anche con il controllo delle versioni. Aspetta ... il controllo delle versioni? Sembra un sistema di controllo del codice sorgente. Meglio conservarlo lì invece.

Aspetta, il linguaggio dei domini non fa X oggi ... lo aggiungeremo ... allora Y ... poi Z ... Ora hai un linguaggio molto complesso che stai mantenendo, che richiede solo tanto quanto mantenere il codice stesso utilizzato, oltre al DSL deve essere mantenuto, quindi qualcuno (probabilmente, a un certo punto, quando l'uomo d'affari si rende conto che non lo capisce abbastanza bene) dovrà mantenere anche il codice DSL e il codice DSL non sarà mai robusto come C #, perché finiresti semplicemente a scrivere di nuovo C #.

Quindi, considera attentamente se vuoi davvero percorrere questa strada. Va bene se si sceglie di farlo, in quanto possono esservi molti vantaggi, ma non pensare che ridurrà effettivamente la complessità o aumenterà la manutenibilità. Sposta semplicemente i problemi.