Problemi trasversali nella struttura del pacchetto per caratteristica

0

Qual è il tuo suggerimento su dove collocare le preoccupazioni trasversali in un'app strutturata per singolo pacchetto? Questo aspetto sembra non essere presente nella maggior parte degli articoli pro pacchetto per articolo che ho letto.

Consideriamo ad esempio una API REST di Java:

com.myapp.authentication
    AuthenticationResource.java
    Token.java
    TokenDao.java
    ...
com.myapp.article
    ArticleResource.java
    Article.java
    ArticleDao.java
   ...
com.myapp.util
    Security.java (hash, random string, etc...)
    ...

Ora, dove posizioneresti l'oggetto User globale e DAO (utilizzato dalla maggior parte delle funzionalità dopo l'autenticazione) e la connessione DB utilizzata dai DAO?

E come gestiresti le transazioni cross-dao?

Stavo pensando che potrebbe avere un metodo startTransaction e endTransaction su ogni DAO e fare affidamento su transacioni annidate. Pensieri?

Un'altra opzione potrebbe essere quella di avere un DaoManager globale da cui il livello di servizio richiederebbe DAO scrivibili / leggibili da, e quindi commettere il risultato al termine. In tal caso, dove inserire una tale classe? Pensieri?

Ritengo che questo sia un punto di partenza così comune per la maggior parte delle app che sto creando, il che mi fa rimanere bloccato così rapidamente.

    
posta user2725580 07.10.2018 - 12:43
fonte

1 risposta

1

Il codice comune che verrà condiviso tra i pacchetti dovrebbe trovarsi in un pacchetto a sé stante. Anche se la tua applicazione è principalmente strutturata per caratteristiche, hai in genere pacchetti aggiuntivi per l'infrastruttura comune, o oggetti dati condivisi, che non possono essere assegnati chiaramente a una funzione, che non è niente di veramente speciale.

Semplicemente non confondere la guida "struttura per pacchetto" per una legge.

    
risposta data 07.10.2018 - 21:46
fonte

Leggi altre domande sui tag