Sta usando la reflection Java per mappare le azioni di frontend ai metodi db effettivi con il nome di cattiva pratica?

0

Ho usato java reflection con una mappa statica per mappare le azioni (removeElements, getLatest ...) dal front-end ai metodi di database corrispondenti per nome in più applicazioni Web ora.

Mi stavo chiedendo se questo uso per la riflessione sia considerato una cattiva pratica? (Ho letto che la riflessione fa fatica a trovare bug)

Se è ciò che dovrei fare invece? (Voglio un unico modo per accedere ai bean di query DB e il front-end non dovrebbe conoscere i nomi dei metodi reali)

Conclusioni:

Quindi per mappare le richieste dal front-end al db vedo queste alternative alla riflessione:

  • REST (azione definita dal metodo http)

  • inferno molti switch / case se / else - > ma questo vorrei considerare peggio di riflessione

posta MADforFUNandHappy 31.08.2017 - 19:40
fonte

1 risposta

1

Suggerirei di stabilire un livello di logica aziendale (BLL). Il livello della logica di business viene chiamato dal livello di presentazione per eseguire il lavoro effettivo dell'applicazione. Questo include cose come:

  • Validation
  • Accesso al database (tramite la collaborazione con i bean di query) che potrebbe essere più complesso di una singola chiamata.
  • Logica condizionale
  • Caching

Questo livello dovrebbe fondamentalmente leggere come i tuoi requisiti di sistema e dovresti fare attenzione a non mettere tutta questa logica nei tuoi bean di query. È opportuno che il front-end chiami la BLL direttamente attraverso le chiamate al metodo. Se si tratta di un back-end a cui accede un client Web, è consigliabile creare un'interfaccia REST sulla BLL. Essenzialmente ogni strato front-end o di presentazione deve passare attraverso la BLL. Ciò rende la tua applicazione coerente. Mentre la tua applicazione potrebbe essere attualmente una semplice mappatura one-to-one che una soluzione di riflessione potrebbe essere in grado di risolvere, è quasi garantito che i tuoi requisiti cambieranno e diventeranno troppo complessi per rappresentare nello schema del database e nel modulo di accesso ai dati.

Oltre a stabilire uno strato intermedio tra il livello di presentazione e l'accesso ai dati, mi raccomando di non utilizzare il riflesso ogni volta che è possibile. Puoi leggere i lati negativi dell'utilizzo della riflessione su quasi tutte le domande di riflessione, ma qui ci sono alcuni problemi con questo:

  • Ampiamente inflessibile - quando si tenta di creare una soluzione basata su riflessione, si sta generalizzando la soluzione (che è buona), ma spesso le limitazioni, i requisiti e gli obiettivi della soluzione sono nascosti. La generalizzazione può essere raggiunta attraverso il polimorfismo. Per esempio se hai il sistema che descrivi, ma ora hai bisogno di passare argomenti, come invochi i metodi attraverso la riflessione, genericamente, e per supportare qualsiasi numero e qualsiasi tipo di argomento? Più difficile da controllare l'istanziazione e l'ambito del bean di query.
  • Elimina il controllo in fase di compilazione. Non puoi garantire che il frontend funzionerà con il backend in fase di compilazione. È necessario scrivere estesi test di integrazione per assicurarsi che non ci siano errori di battitura o errori di configurazione nel sistema. Anche in questo caso, la configurazione di produzione potrebbe non essere configurata correttamente e non essere rilevata dai test.
  • Più difficile da seguire. Non puoi tracciare gli usi dei tuoi metodi nel sistema con l'IDE, invece devi fare affidamento sulla ricerca di file per trovare le chiamate configurate dei tuoi metodi.
risposta data 31.08.2017 - 20:31
fonte