"Best practice" durante la progettazione di applicazioni di grandi dimensioni con più funzioni

3

Prima un po 'di storia. Mi è stato affidato il compito di riscrivere il software della nostra pistola in VB.Net (convertendo il codice da BBJ). Questo software incorpora molte diverse funzioni di gestione dell'inventario, come l'esecuzione di mosse azionarie, indagini azionarie, cambio di stato delle scorte, raccolta di merci da inserire in cartoni e una moltitudine di altre operazioni. Sono anche relativamente nuovo nel progettare qualcosa di questa scala da zero (più o meno).

Ho già sviluppato un sistema di menu, utilizzando un TreeView che viene compilato dinamicamente in base alla configurazione del profilo dell'utente nel nostro sistema (in modo che possano accedere solo alle opzioni disponibili per la loro posizione).

La mia domanda entra in gioco quando si progetta il software e si tiene separato il codice per tutte le diverse voci di menu. È considerata una "buona pratica" creare un progetto separato per ciascuna voce di menu in uno scenario come questo? La maggior parte delle funzionalità è separata l'una dall'altra (IE: il codice per il prelievo non ha bisogno di accedere al codice per le mosse azionarie, e allo stesso modo il codice di spostamento delle scorte non dovrebbe accedere alla logica dello spaccato diretto).

Sto cercando di mantenere la soluzione il più pulita possibile, in modo che non ci imbattiamo in cose come un'opzione di menu con funzioni o risorse denominate in modo simile a un'altra, ecc. E inoltre possiamo "inserire" nuove funzionalità se necessario. L'idea è che io e un altro programmatore lavoreremo principalmente su questo codice, e ho pensato che se dividiamo il codice in progetti, possiamo semplicemente includere un progetto quando una nuova funzione è completata, aggiungendo le risorse se necessario. Qualche raccomandazione?

    
posta RianBattle 10.02.2016 - 15:29
fonte

1 risposta

3

Se mappi elementi di menu diversi su

  • la stessa funzione con diversi parametri

  • diverse funzioni all'interno della stessa classe

  • diverse classi all'interno dello stesso assembly, con una funzione di inserimento standard

  • DLL diverse, ognuna con un punto di accesso standard definito da un'interfaccia speciale

  • diversi eseguibili, ognuno con parametri di riga di comando standard

dipende interamente da te. Tutti questi approcci possono essere progettati "puliti", senza duplicazioni di codice non necessarie e configurabili. Ti consiglierei di scegliere una soluzione con un livello di astrazione adatto alle tue esigenze (più astratto che deve essere, ma non di più) e, se possibile, scegliere one delle strategie di cui sopra all'interno un sistema di applicazione.

Fai attenzione a non sovradimensionare questo problema cadendo nella trappola del secondo effetto di sistema .

    
risposta data 10.02.2016 - 17:42
fonte

Leggi altre domande sui tag