Utilizzo di bean prototype / non-Spring nell'applicazione Spring Web

Ho lavorato a progetti Spring di varie dimensioni, da microservizi di piccole dimensioni (a volte meno di 100 righe di codice di produzione) fino a grandi monoliti (con oltre 20 sviluppatori a tempo pieno che lavorano su base di codice singolo).

Prima di tutto , la mia esperienza è che i monoliti tendono a essere spesso troppo complicati e pieni di complessità accidentale accumulata. Pertanto, se ritieni che il tuo team stia verificando inefficienze causate da codice eccessivo, dovresti prendere in considerazione la possibilità di suddividerlo in componenti più autonomi e gestibili separatamente. Non importa se usi Spring.

In secondo luogo , forse hai riscontrato un movimento di programmazione funzionale che sta prendendo il sopravvento sulla community di alpha geek. Una delle idee fondamentali della programmazione funzionale è la rigorosa separazione tra codice e dati. I programmatori effettivamente funzionanti credono strongmente che sia una pessima idea combinare dati (stato) con il codice in oggetti, come spesso accade nella programmazione orientata agli oggetti.

Personalmente ritengo anche che incapsulare lo stato in un mucchio di oggetti e definire la logica su questi oggetti per mutare questo stato creerà enormi problemi in applicazioni monolitiche. Non importa quanto grandi sviluppatori hai sul progetto, creeranno basi di codice difficili da mantenere, poiché i problemi delle mutazioni di stato sono spesso molto difficili da riprodurre e scoprire.

A tale riguardo, l'ambito Singleton predefinito di Spring rende la base di codice molto più semplice , perché dovresti sempre cercare di non definire alcun stato sui bean singleton . Pensateli solo come un codice, in cui tutti sono rigorosamente privi di stato.

Lo stato nella tua applicazione rappresenta un problema di scalabilità, perché se hai un'applicazione stateful non puoi avere varie istanze di essa. Quindi lo stato dovrebbe essere sempre gestito con cura in cache o depositi dedicati allo stato di archiviazione (ad esempio cache distribuite o griglie di dati o database).

Ora al primo punto elenco , non provare a iniettare bean non Spring nei bean singleton Spring. Lavoro con Spring 5+ anni e posso ricordare solo un caso in cui ho usato lo scope Prototype. Basta creare i tuoi DTO tramite costruttore e non mescolarli con il contesto di Spring. È una buona idea mantenere questi DTO il più possibile. Ciò significa che utilizzare crea solo getter / setter / toString e hashcode / equals per loro se necessario. Consiglio vivamente di utilizzare il progetto Lombok per generare questi metodi standard, in modo che i DTO siano molto leggibili.

Al punto relativo a molti parametri che passano intorno . Basta raggruppare questi parametri in DTO di livello superiore. Per esempio. se si passano i parametri: customerName, customerId, customerCreditCardNumber, basta creare il cliente DTO e trasferirlo. Abbastanza facile Se non vuoi passare nulla, usa l'ambito Richiesta per associare lo stato alla richiesta corrente. Tutti i bean possono autorizzare questo bean dell'ambito della richiesta e mutarne lo stato. Ma questo dovrebbe essere un caso molto raro e eccezionale in quanto potrebbe nascondere spesso comportamenti ingannevoli. È equivalente alla variabile globale per richiesta. Cattiva idea in generale.

Al secondo punto elenco . Credo che fosse già trattato con i miei altri punti.

So che questi approcci stanno deviando significativamente da ciò che abbiamo appreso al college quando l'approccio OOP è stato preferito. Ma l'industria comincia lentamente a rendersi conto che non è il giusto approccio per la scrittura di applicazioni web complesse. Consiglio vivamente di esaminare i principi di programmazione funzionale come sembrano essere il futuro.