Livello di servizio dell'applicazione che chiama le funzioni del database. Cattiva architettura?

Scenario:

• Stack: Java, Spring, Hibernate.
• Modello: applicazione client-server.
• Modello: Model-View-Controller (MVC).

Le classi del livello di servizio hanno tre comportamenti:

1. Alcuni servizi hanno la regola aziendale all'interno dei metodi e delegano la persistenza all'applicazione. Piace:

   EntityManager.save (entità);

2. Alcuni servizi chiamano semplicemente una funzione di database (passando parametri) Come:

   CallableStatement cls = con.prepareCall ("{call databaseFunction (args)}");

3. Alcuni servizi hanno metodi con entrambi i comportamenti.

Le mie domande:

1. C'è qualche problema ad avere i servizi dell'applicazione che chiamano direttamente le funzioni del database? Non è considerata una cattiva pratica? Quale sarebbe un modello di architettura applicabile a un progetto come questo?
2. C'è qualche problema ad avere il mix di comportamenti nello stesso servizio? Come transazioni e coerenza?
3. In caso di manutenzione, questo incapsulamento rende oscuro allo sviluppatore che dovrebbe anche modificare le funzioni nel database? Come evitarlo?
4. Questo scenario si verifica in altre applicazioni in tutto il mondo o è stato solo un errore architettonico?

C'è qualche problema ad avere i servizi dell'applicazione che chiamano direttamente le funzioni del database? Non è considerata una cattiva pratica?

Penso che ci sia. Stai mettendo una conoscenza degli interni del database al servizio dell'applicazione. La modifica del database in qualsiasi modo (modifica del motore di archiviazione o persino la ridenominazione di un campo o la creazione di un indice) potrebbe richiedere la modifica del servizio dell'applicazione e ciò viola la SRP .

Quale sarebbe un modello di architettura applicabile a un progetto come questo?

Vedi il commento qui sotto.

C'è qualche problema ad avere il mix di comportamenti nello stesso servizio? Come transazioni e coerenza?

Non credo ci sia un problema tecnico, ma ce n'è uno logico. Basta mescolare due approcci nell'applicazione rendendolo vago, meno strutturato, difficile da adattare ai cambiamenti. Vedi anche i commenti sopra sulla violazione di SRP.

In caso di manutenzione, questo incapsulamento rende oscuro allo sviluppatore che dovrebbe anche modificare le funzioni nel database?

Certo che lo fa.

Come evitarlo?

Posiziona metodi e funzioni, che funzionano direttamente con il database in un livello separato di astrazione (che si tratti di un livello DAO o di un modello di repository semplice, dipende dalla complessità dell'applicazione)

Questo scenario si verifica in altre applicazioni in tutto il mondo o è stato solo un errore architettonico?

Penso che nel nostro mondo tutto accada;)

Secondo quello che hai detto c'è un livello di servizio, quindi il modello architettonico che sembra adatto è l'architettura a strati. Ulteriore riferimento

Sì, di solito è una cattiva pratica effettuare chiamate dirette al database oltre a un livello di accesso ai dati, in questo modo il livello aziendale accede solo a un'astrazione del database.

Per quanto riguarda i comportamenti di mixaggio, l'uso di alcuni pattern di design come pattern DAO o Repository potrebbe aiutare a delegare tali responsabilità migliorando così quel codice.

Alcuni dei vantaggi dell'utilizzo di un modello di progettazione e di un ORM sono la leggibilità del codice, l'incapsulamento delle responsabilità, quindi se l'accesso al database cambia il livello aziendale non dovrebbe cambiare molto.