Considerazioni di architettura nella progettazione di applicazioni per console?

Question

Ho recentemente programmato un'applicazione per console e ho sperimentato molto dolore nel progettarlo in molti aspetti, in particolare in C#, dato il suo puro paradigma OO. Le domande che ho affrontato comprendono qualsiasi cosa, da come passare le opzioni a come restituire i problemi alla classe del punto di ingresso, tra molti, molti altri.

La mia domanda è: qualcuno di voi saprebbe dei buoni progetti di applicazioni di console in un paradigma OO, quindi posso imparare da loro? Il codice di buone implementazioni è in particolare benvenuto.

EDIT: Non mi occupo delle API da riga di comando, ma dopo i buoni principi di progettazione e, in particolare, le buone implementazioni da cui ho potuto imparare.

EDIT 2: C'è una semplice interazione dell'utente nell'applicazione, ma non è un ordinamento CLI/REPL completo. Pensalo come il comando TeX, più o meno. È interessante notare che, anche se c'è una buona teoria che fluttua intorno (non diversa da X, usa il pattern Y, dovresti conoscere i principi OO ... [il tuo professore di informatica sarebbe così orgoglioso!]), Non esiste un codice reale che possa prendere guarda per vedere questi concetti in azione. Di nuovo, dove dovrei guardare (codice!) Per una buona applicazione da riga di comando in un paradigma OO puro?

Answer 1

Sembra che tu stia costruendo un'interfaccia che esegue una delle numerose operazioni distinte con ogni invocazione. Non sono sicuro se ti riferisci a un'applicazione "da riga di comando" (che esegue un'azione, poi esce) o un'applicazione CLI (che visualizza un prompt e risponde ripetutamente all'input dell'utente). In generale, il primo sarà molto più semplice da costruire rispetto al secondo; Penso che abbia senso solo usare una CLI se l'applicazione richiede uno stato persistente che evolve su più comandi. Se stai affrontando qualcosa come questo, allora alphazero è corretto - dovresti probabilmente imparare REPL e copiarne uno buono.

In ogni caso, l'operazione eseguita dipenderà gli argomenti passati sulla riga di comando, quindi mi brainstorming di quella parte ...

Si pensi sensibile dell'applicazione come un insieme di distinti " Comanda "oggetti, uno per ogni tipo di operazione. Il punto di accesso all'applicazione dovrebbe quindi essere una sorta di oggetto CommandLineDispatcher che invia richieste all'oggetto Command appropriato.

Per essere modulare, il dispatcher deve essere configurato con una mappatura astratta (ad esempio un Hashtable) per associare ciascun token di comando (di solito la prima parola della stringa della riga di comando) all'oggetto Command che lo gestisce. Il dispatcher può anche gestire l'analisi delle opzioni comuni, probabilmente usando una libreria "getopts" pronta per il sollevamento pesante.

Per iniziare in modo semplice, ciascun oggetto Command può implementare un'interfaccia coerente per eseguire il proprio lavoro; forse qualcosa di simile:

public void execute(List<String> args) 

In questo modo, il dispatcher entry-point trova solo il Comando stato richiesto, e executes esso.

Riguardo alla gestione degli errori: il metodo execute() potrebbe semplicemente generare un'eccezione per comunicare errori ... È possibile che l'eccezione venga rilevata ed elaborata dal dispatcher o semplicemente registrata sullo schermo. In alternativa, i comandi in errore potrebbero richiamare alcune funzioni condivise di usage per combinare un messaggio di errore con istruzioni generali. Non credo che il "punto di ingresso" debba essere necessariamente reso consapevole dei problemi che suggerisci; se hai bisogno di una solida gestione degli errori (ad esempio, per le funzionalità di registrazione o di avviso), sembra che appartenga a un componente separato che potrebbe essere fornito all'oggetto Command.

In generale, un'applicazione della riga di comando non è diversa da qualsiasi altra applicazione che risponde all'input dell'utente: è necessario un dispatcher per analizzare e instradare l'input e gestori (ovvero "controller") per eseguire l'operazione. operazioni supportate. Se hai bisogno di altri servizi (registrazione, avviso, connettività del database, ecc.), Farai bene a creare componenti separati per isolare questa logica ed esporla con interfacce pulite.

Answer 2

un'applicazione console è alcun modo diverso da una forma vittoria regolari o applicazione web quando si tratta di importanti preoccupazioni trasversali come la registrazione, l'errore e la gestione delle eccezioni, la sicurezza, ecc.,

Detto questo potete per favore dettaglio la nostra domanda su dove sono le principali aree di interesse?

È possibile disegnare su più modelli da App Architecture Guide da Microsoft.

Answer 3

In Java uso spesso Apache CLI, ho cercato su google "CLI for .NET" ma sembra che non sia ancora stata implementata. Forse è utile leggere l'approccio Java per ricevere i parametri della console.

Per l'architettura della tua app, non dovrebbe essere molto diverso dall'architettura che useresti in una Web App, la differenza è che la console è l'interfaccia del tuo livello di presentazione. Forse puoi definire alcuni 'ConsoleControllers' per ricevere il modello dal livello aziendale alla console e viceversa. Pensa a ogni input dell'utente come richiesta;).

Answer 4

Nella sua più (estrema) senso generale, un'applicazione console è un tipo di REPL:

http://en.wikipedia.org/wiki/REPL

Ovviamente, un dominio specifico (console) applicazione non sostiene un linguaggio completo Turing, ma molti dei problemi si sovrappongono e un buon REPL deve essere un'applicazione di riga di comando molto solida. Sono sicuro che puoi imparare molto studiando la progettazione e l'implementazione di un tipico REPL. (La maggior parte dei REPL sono open source. (Prova Ruby o Python per REPL OO))

Answer 5

Per un programma per avere una buona progettazione architettonica soprattutto in C# è necessario avere familiarità con i concetti di progettazione OO tenere pienamente advanage di OO paradigmi