Distingua tra comandi UI e comandi di dominio

4

Sto creando un'applicazione client WPF utilizzando il pattern MVVM che fornisce un'interfaccia su un set esistente di business logic che risiede in una libreria condivisa con altre applicazioni. La libreria di business ha seguito un'architettura basata sul dominio che utilizza CQRS per separare i modelli di lettura e scrittura (nessun evento di approvvigionamento). La combinazione di tecnologie e schemi ha sollevato un enigma interessante:

  • Il pattern MVVM utilizza lo schema di comando per la gestione interazione dell'utente con i modelli di visualizzazione. .NET fornisce un ICommand interfaccia che è implementata dalla maggior parte dei framework MVVM, come MVVM Light's RelayCommand and Prism's DelegateCommand. Ad esempio, il modello di visualizzazione esporrà un numero di oggetti comando come proprietà che sono associate all'interfaccia utente e rispondono quando l'utente esegue azioni come i pulsanti di selezione.
  • Molte implementazioni del CQRS usano il modello di comando per isolare e incapsulare i comportamenti individuali. Nella mia biblioteca aziendale, abbiamo implementato il modello di scrittura come coppie comando / comando-gestore. Pertanto, quando vogliamo fare del lavoro, come creare un nuovo ordine, emettiamo un comando (CreateOrderCommand) che viene instradato al gestore di comandi responsabile dell'esecuzione del comando.

Questo è bello, chiaramente spiegato in molte fonti e io sono bravo con esso. Tuttavia, prendi questo scenario:

I have a ToolbarViewModel which exposes a CreateNewOrderCommand property. This ICommand object is bound to a button in the UI. When clicked, the UI command creates and issues a new CreateOrderCommand object to the domain which is handled by the CreateOrderCommandHandler.

Questo è difficile da spiegare agli altri sviluppatori e mi sto ritrovando legato alla lingua perché tutto è un comando.

Sono sicuro di non essere il primo sviluppatore a sovrapporre pattern come questo, dove anche la denominazione / terminologia si sovrappone. In che modo ti sei avvicinato distinguendo i comandi utilizzati nell'interfaccia utente da quelli utilizzati nel dominio?

(Modifica: dovrei menzionare che la business library è indipendente dall'interfaccia utente, cioè non esiste un codice specifico della tecnologia UI, o che esisterà, in questa libreria.)

    
posta SonOfPirate 05.12.2012 - 04:21
fonte

1 risposta

3

Tendo a risolvere questi conflitti di denominazione semplicemente scegliendo nomi diversi.

Forse hai già iniziato a chiamare queste cose con nomi diversi internamente, in tal caso, se il codebase lo riflette. In caso contrario, pensa a qualcosa (UserCommand vs WriteCommand, Command vs Request, Action vs Command ...)

Fondamentalmente, il sovraccarico della parola "comando" crea confusione, quindi cambia la terminologia. Significa deviare dai nomi dei modelli di design standard, ma è meglio della confusione costante.

La terminologia non è Vangelo. La terminologia utilizzata dai modelli di progettazione dovrebbe rendere più facile parlare del software. Se fa il contrario, cambialo (e documentalo e perché lo hai fatto)

    
risposta data 13.05.2013 - 16:25
fonte

Leggi altre domande sui tag