Hai bisogno di consigli per quanto riguarda la soluzione a strati, la separazione delle preoccupazioni, ecc

Question

Abbiamo un'applicazione a più livelli, o almeno è in procinto di passare a una, suddivisa come segue:

• Interfaccia (interfaccia utente o interfaccia dell'applicazione, ad es. webservice, ecc.)
• Logica aziendale
• Accesso ai dati

Per rendere il resto di questa domanda più concreta, descriverò un'istanza specifica.

Abbiamo un'interfaccia utente, che ha dietro un oggetto controller (il livello di logica aziendale). Questo controller comunica con il database tramite un altro oggetto (il livello di accesso ai dati).

In un determinato contesto, l'interfaccia utente consente all'utente di scegliere un dipendente a cui legare l'operazione. Dal momento che ci sono delle regole per quanto riguarda i dipendenti che l'utente (beh, qualsiasi mondo al di fuori del controller può davvero scegliere), il controller fornisce due cose per questo:

• una proprietà leggibile contenente un elenco di dipendenti disponibili tra cui scegliere
• una proprietà leggibile / scrivibile contenente il dipendente attualmente selezionato

L'interfaccia utente potrebbe leggere l'elenco e usarlo per popolare una casella combinata.

Nella versione 1 di questa applicazione, la casella combinata contiene il numero identificativo dell'impiegato + il nome dell'impiegato.

Va ??tutto bene ...

... fino alla versione 1.1, un bugfix. Un utente si lamenta di non poter scegliere tra Jimmy Olson e Jimmy Olson perché l'applicazione non gli rende abbastanza facile sapere quale sia. Sa che c'è un Jimmy nel reparto vendite e un altro nel reparto sviluppo, quindi la soluzione per questa versione 1.1 è semplicemente quella di attaccare una barra + il nome del reparto nella casella combinata. Nella versione 2 sceglieremmo di sostituire la casella combinata con una casella combinata con supporto per colonne, rimuovendo la barra, ma in 1.1, questo è ciò che viene scelto per ridurre al minimo il rischio di ulteriori bug.

In altre parole, la casella combinata conterrebbe:

• 1 - Jimmy Olson / Vendite
• 2 - Jimmy Olson / Sviluppo
• • altre persone

Tuttavia, il codice dell'interfaccia utente non ha codice SQL, o alcun modo per ottenere quel reparto, e quindi dobbiamo andare al controller e guardare il codice lì. Il responsabile del trattamento non ha bisogno del dipartimento e, ad essere onesti, non ha nemmeno bisogno del nome dell'impiegato, il numero identificativo è sufficiente, quindi nel controller non c'è nulla che richieda o faccia qualcosa al dipartimento. Quindi dobbiamo passare al livello di accesso ai dati e modificare qui l'SQL.

Questa soluzione ha un odore francamente.

Se ci sono più interfacce per questo controller, con requisiti diversi, abbiamo tre possibili soluzioni:

1. Modifica il livello di accesso ai dati per soddisfare le esigenze (crescenti / diverse) di più interfacce (a 2 livelli di distanza), il che significa che tutte le interfacce otterranno probabilmente tutti i dati di cui hanno bisogno, ma otterrebbero anche tutti i dati richiesto per una qualsiasi delle altre interfacce
2. Aggiungi qualcosa che permetta all'interfaccia utente di dire al livello di accesso ai dati (distante ancora 2 livelli) di cosa ha bisogno
3. In qualche modo fai in modo che il livello dell'interfaccia utente acquisisca i dati richiesti senza cambiare il controller o il livello di accesso coinvolti, sembra che abbiamo bisogno di più codice di accesso ai dati, da qualche parte.

Nessuna delle soluzioni di cui sopra si sente bene.

Quello che mi chiedo è: siamo completamente fuori rotta? come lo faresti? Esiste una quarta e quinta soluzione al di sotto delle 3 sopra?

Per questa domanda: Separation of Concerns , la risposta accettata contiene questa citazione:

  

La separazione delle preoccupazioni sta mantenendo il codice separato per ciascuna di queste preoccupazioni. La modifica dell'interfaccia non dovrebbe richiedere la modifica del codice della logica aziendale e viceversa.

Significa semplicemente che tutto il livello di accesso al controller / dati

Answer 1

Per come la vedo io, hai due possibilità:

1. Chiedi ai livelli inferiori di inviare tutto le informazioni che hanno su a persona, possibilmente come documento XML, anche se molti dei consumatori di quell'informazione non ha bisogno di tutto.
2. Fornisci API per il livello superiore strati per eseguire il drill down e ottenere il le informazioni di cui hanno bisogno. Quindi nel caso tu dia, avere un metodo che l'interfaccia può chiedere all'azienda livello per richiedere il livello di database il dipartimento ha fornito l'id utente.

Entrambi hanno dei compromessi. Il primo espone molte più informazioni, possibilmente ai consumatori che non hanno alcun diritto a tali informazioni. Il secondo passa molte meno informazioni per transazione, ma richiede più transazioni. Il primo non richiede una modifica all'API ogni volta che si hanno più informazioni, ma cambia l'XML. Il secondo mantiene la stessa interfaccia delle API esistenti, ma fornisce nuove API in base alle esigenze. E così via.