Funzioni del database di chiamata del livello servizio applicazioni. Cattiva architettura?

Naviga le tue risposte
10

Scenario:

  • Stack: Java, Spring, Hibernate.
  • Modello: applicazione client-server.
  • Pattern: 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. Come:

    EntityManager.save (entità);

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

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

  3. Alcuni servizi hanno metodi con entrambi comportamenti.

Le mie domande:

  1. C'è qualche problema nell'avere chiamate di servizi applicativi - direttamente - funzioni del database? Non è considerata una cattiva pratica? Quale sarebbe un modello di architettura applicabile a un progetto come questo?
  2. C'è qualche problema nell'avere il mix di comportamenti nello stesso servizio? Quali transazioni e consistenza?
  3. In caso di manutenzione, questo incapsulamento rende oscuro allo sviluppatore che dovrebbe anche cambiare le funzioni nel database? Come evitare questo?
  4. Questo scenario si verifica in altre applicazioni in tutto il mondo o è stato solo un errore architettonico?
posta linuxunil 06.12.2016 - 14:05
fonte

2 risposte

7

Is there any problem in having application services call - directly - database functions? Is not this considered bad practice?

Penso che ci sia. Si sta mettendo una conoscenza degli interni del database al servizio dell'applicazione. Cambiare il database in qualsiasi modo (cambiando il motore di archiviazione o rinominando un campo o creando un indice) potrebbe richiedere la modifica del servizio dell'applicazione e questo viola SRP .

What would be an architecture model applicable to a project like this?

Vedi il commento di seguito.

Is there any problem in having the behavior mix in the same service? Such as transactions and consistency?

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

In the case of maintenance, does this encapsulation make it obscure to the developer that he should also change the functions in the database?

Certo che lo fa.

How to avoid this?

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 semplice modello di repository, dipende dalla complessità della tua applicazione)

Does this scenario happen in other applications around the world or was it just an architectural error?

Penso che nel nostro mondo tutto accada;)

    
risposta data 07.12.2016 - 15:34
fonte
3

In base a ciò che hai detto c'è un livello di servizio, quindi il modello architettonico che sembra adatto è Layered Architecture. Ulteriori riferimenti

Sì, di solito è una cattiva pratica effettuare chiamate dirette al database sull'altro che non 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'utilizzo di alcuni pattern di progettazione come pattern DAO o pattern Repository potrebbe aiutare a delegare tali responsabilità migliorando così quel codice.

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

    
risposta data 07.12.2016 - 07:09
fonte

Leggi altre domande sui tag

Quanto è comune la meta-programmazione? [chiuso] TDD Verifica chiamata fittizia - è un anti-pattern?