MVC, Servizi e DAO: scelte di progettazione fondamentali, gestione degli errori e valori di ritorno

1

Modifica: non c'è una risposta "giusta" o "sbagliata" qui, stavo solo cercando di convincere le persone a condividere le loro cose da fare e da non fare.

Dietro questo argomento piuttosto vago vorrei affrontare alcuni problemi che ho avuto nei miei ultimi progetti. Come regola generale, cerco di mantenerlo semplice, seguire schemi di progettazione e il principio di Responsabilità Singola. Ma tutte queste cose lasciano alcune domande senza risposta, o almeno non chiare.

Consideriamo questo esempio semplificato di una tipica WebC MVC dal Gui al livello di persistenza (solo snippet e pseudo-codice):

View.xhtml

<h:form>
    <p:inputText value="#{model.text}" />
    p:commandButton value="Save" actionListener="#{controller.saveToDb}" />
</h:form>

Model.java

String text;
String getText();
void setText(String text);

Controller.java

@Inject Model
@Inject Service
public void saveToDb(){
service.saveToDb(Model.getText());
}

Service.java

@Inject dao

public void saveToDb(String text){
Entity entity = new Entity(text);
dao.persist(entity);

Questo è solo un illutration, ma immagina diversi metodi su ogni livello, controllori che chiamano servizi e servizi che si chiamano a vicenda. (Alcuni vecchi studenti potrebbero voler aggiungere una facciata tra il controller e il servizio).

Tenendo presente questo concetto, ecco alcune domande:

  • Cosa devono restituire i metodi? Vuoto ed Eccezioni in caso di errori? POJ dei risultati personalizzati con valori?

  • Come implementare la gestione degli errori? Eccezioni controllate o non selezionate? Gestisci un'eccezione Service localmente (se sì, cosa restituisci?) O la invii al chiamante?

  • Va bene per i controller chiamare altri controller?

  • Abbiamo davvero bisogno di un oggetto Value e di oggetti Data Transfer per ogni caso d'uso? Perché non rimandare le entità?

  • Il servizio dovrebbe controllare i parametri, o dovrebbe solo elaborare i dati, supponendo che sia stato controllato prima ed è corretto?

  • Durante il controllo dei dati, è OK avere diversi controlli sequenziali e tornare non appena si fallisce? (Domanda bonus: is è disapprovato per tornare in un vuoto?)

Informazioni sulla singola responsabilità: immagina uno scenario in cui desideri creare un pojo, inviarlo per post http e mantenerlo attivo. Avresti:

  • Un servizio per creare il pojo
  • Un servizio per inviarlo tramite post http
  • Un servizio per mantenerlo
  • Un controller che reagisce a un pulsante cliccato sulla vista

Come e dove combini i due? Il controller chiama il metodo di servizio di creazione, quindi se ha successo il metodo di servizio di invio e infine il metodo di servizio persistente?

O c'è un metodo nel controller chiamato "createSendAndPersist ()" che chiama a turno tutti e 3 i metodi di servizio? Come gestisci gli errori in questo caso?

Lo so, ci sono molti modi per farlo e non c'è una risposta "giusta". Ma quali sono le migliori pratiche? Cosa ha funzionato meglio per te?

    
posta Tim 22.07.2016 - 16:25
fonte

1 risposta

2

Do we really need a Value Object and Data Transfer Objects for every use case? Why not send back entities?

OK, sto solo cercando di rispondere a questa delle tue molte domande.

Opzione 1: se il tuo database modella esattamente la tua attività e non ci sono regole di business arcane, allora usa tutti gli oggetti entità nel tuo livello di interfaccia grafica. La programmazione sarà semplice ed elegante, in quanto la GUI sta semplicemente esponendo il tuo modello di business. Basta tenere a mente che, se il modello aziendale dovesse cambiare, sarà necessario aggiornare lo schema del database per riflettere la modifica e aggiornare la GUI e possibilmente molti report adatti. Secondo me questa è la strada da percorrere, soprattutto per un progetto greenfields.

Opzione 2: aggiungi un paio di livelli di astrazione tra il database e la GUI. Implementare quelle regole commerciali sempre più arcane nel livello "business" e raramente. se mai, cambia lo schema del database. Tra qualche anno avrai un disordine irraggiungibile. Ogni nuova funzione dovrà essere ottimizzata per supportare le soluzioni alternative rispetto alle precedenti aggiunte alle funzionalità.

Ho lavorato con entrambi, e l'Opzione 1 è sicuramente la strada da seguire per il futuro. Sfortunatamente non hai sempre una scelta.

    
risposta data 25.07.2016 - 11:07
fonte

Leggi altre domande sui tag