linee sfocate tra livello di contesto dell'applicazione Web, livello di servizio e livello di accesso ai dati in primavera

3

Devo ammettere che sono un principiante di primavera, ma puoi correggermi se sbaglio, questa fodera sembra un po 'squallida in un modo pratico:

@RepositoryRestResource(collectionResourceRel="people"...)
public interface PersonRepository
extends PagingAndSortingRepository<Person, Long>

Per coloro che non sono consapevoli, ciò che segue fa molte cose: è una definizione di interfaccia che può essere registrata in un contesto applicativo come un repository jpa, agganciando automaticamente tutte le operazioni CRUD predefinite all'interno di un contesto di persistenza (che è configurato esternamente ). e configura anche la funzionalità di default controller / richiesta-mappatura / gestore nello spazio dei nomi "/ persone" relativa alla mappatura servlet del dispatcher configurato.

Ecco il mio punto. Ho appena attraversato 3 livelli concettuali con una riga di codice! questo è contro il mio istinto di separazione, ma volevo sentire la tua opinione. E per il piacere di trovarmi in un sito di domande e risposte, vorrei sapere se esiste un modo migliore per separare questi diversi livelli: servizio, dati, controllori, pur mantenendo la configurazione minima possibile

    
posta thenaglecode 10.06.2014 - 04:25
fonte

2 risposte

1

Dichiarazione di non responsabilità: non conosco quell'annotazione, quindi la mia risposta sarà nella tua definizione.

Quando programmiamo, usiamo i livelli perché altrimenti, durante la programmazione, rischiamo di correre in una serie di problemi noti. Ma se quella linea di codice è tutto ciò di cui hai bisogno per costruire tutte le funzionalità relative a un oggetto business, non lo programmerai più, quindi non dovrai dividere il codice in livelli (perché non c'è alcun codice da dividere ).

Se lo fa da solo, lo considererei più come Spring che fornisce un "componente" esterno alla tua applicazione.

Ad esempio, se si stesse utilizzando un client LDAP per gestire utenti e permessi, non ci si preoccuperebbe che usando quel client si stiano "incrociando" i livelli concettuali. Questo è un problema "interno" al client / server LDAP e tu usi semplicemente l'astrazione del servizio LDAP.

Ovviamente, prima di usarlo, devi decidere se accedere direttamente a questi oggetti di business. Inoltre, analizzo come questo "componente" possa interagire con il resto dell'applicazione. A prima vista, posso pensare a questi problemi:

  • Ti fidi di Spring per implementare correttamente il componente?

  • Supporta qualche tipo di schema di integrazione (forse un modello di osservatore, quindi la logica aziendale può sapere quando un oggetto viene modificato attraverso il componente)?

  • Quali sarebbero i passi da compiere se si desidera aggiungere, ad esempio, un'interfaccia utente Web che acceda agli stessi dati? Saresti in grado di collegarti ai "metodi CRUD" o dovresti replicare la funzionalità?

risposta data 10.06.2014 - 15:15
fonte
1

Non ho mai usato quell'annotazione da solo, e ho il sospetto che sia per la ragione che hai descritto. Sì, hai una preoccupazione totalmente valida lì. Ad un livello minimo, usa solo @Repository , @Service , @Controller con <context:component-scan base-package="your.base.package" /> . È possibile utilizzare i generici a livello di DAO se si desidera creare operazioni CRUD generiche.

Tale annotazione (sospetto) sembra essere stata progettata per essere utilizzata in Spring Security quando si tenta di autenticare gli utenti utilizzando una chiamata REST.

Tuttavia, non utilizzerei affatto quella particolare annotazione nella mia applicazione per esattamente il motivo per cui la descrivi.

    
risposta data 10.06.2014 - 05:07
fonte

Leggi altre domande sui tag