[OT] Dove è meglio collocare la parte "model" di un'applicazione?

[Shadow976]

Scusandomi con Alka per i disagi arrecati apro questo topic sperando di essere quanto più mirato possibile e sperando che non esuli dalle usuali richieste che non rientrano nel pagamento di un consulente. Non posso dire che Alka abbia detto cose sbagliate, quindi accetto e mi adeguo.

Nella mia web application in Java e Postgre sviluppata secondo i dettami MVC, la parte model è al momento situata in un particolare package, al quale competono anche tutte le query sia di selezione che di aggiornamento. A breve, contavo di studiare Hibernate per poter integrare anche questo potete strumento. Ho saputo però nella precedente discussione che anche integrare scripr nel db, delegando ad essi ogni operazione, è una ottima cosa. A chi ben conosce Hibernate, Postgre ed i dettami MVC, domando semplicemente quale sia la scelta migliore:

1. Java. Lasciare la parte Model dove si trova ora, magari riservandomi di integrarla con Hibernate;
2 SQL / C. Spostare tutta la parte model nel database, delegando ogni operazione alle stored procedure;
3. Entrambe. Delegare le operazioni di lettura e scrittura alle stored procedure, creare comunque nel mio applicativo una parte model con la quale richiamarle, e nel caso integrare in futuro tale parte con Hibernate.

Spero di essere stato abbastanza mirato e conciso e vi ringrazio in anticipo.

[standard]

non c'è una risposta giusta o una sbagliata. O forse la risposta giusta c'è ed è: dipende.
Da un'infinità di fattori chiari e meno chiari (che spesso si chiariscono col tempo...purtroppo) in cui è immerso il tuo progetto.

Da un punto di vista di "pulizia" potrebbe essere buona cosa centralizzare le logiche di business (magari utilizzando "poche" tecnologie). Ma la "pulizia" non è (sempre "purtroppo") il driver che guida le scelte nei sistemi informatici o gestionali.

Da quel che ho inteso, se hai intenzione di utilizzare Hibernate, potrebbe non essere una scelta felice quella di portare logiche di business sul DB. Potrebbe essere preferibile avere un middle-layer (magari un progetto a se stante) in cui risiedano le logiche di business da applicare alle tue entità Hibernate.

[Shadow976]

Ho valutato la tua risposta, di fatto mi dici che non c'è una soluzione assoluta; mi sono quindi ritenuto libero di compiere le mie valutazioni in base a fattori diversi. Ad esempio, ho guardato le dimensioni dei vari pacchetti di Hibernate rispetto alle dimensioni attuali della mia applicazione: enormi. Tutti i pacchetti che mi sarebbero stati utili avrebbero aumentato le dimensioni della mia applicazione di circa 5 volte.

Mi trovo quindi di fronte a due scelte: la prima, usando Hibernate e portando il Model nell'applicazione, appesantire enormemente l'applicazione stessa per disporre di funzioni che, pur gestite in modo diverso, avrei comunque. La seconda, alleggerire non di poco il carico di lavoro visto che ad esempio la mia applicazione non dovrebbe più trasmettere al db le informazioni sulle query, che risiederebbero nello stesso db.

Sceglierò la seconda soluzione, e sfrutterò a fondo le possibilità offerte dal db. Per tutto quello che riguarda visualizzazioni utilizzerò le viste, un pò più veloci delle stored procedure; userò invece queste ultime per tutte le altre operazioni.

Manterrò la portabilità del mio progetto su diversi motori db, creando alcuni script diversi per i più diffusi db (a questo punto non si può più pensare di realizzare un unico script per qualsiasi motore db, fosse solo per i diversi linguaggi usati nelle stored procedure); la mia applicazione invece sarà sempre la stessa, visto che cambiando db cambia la sintassi interna ma non certo quella della mia applicazione per richiamare i vari oggetti in esso contenuti.

Mi ritengo soddisfatto della tua risposta, che ha aperto la strada a tutte queste riflessioni. Il quesito si può considerare concluso.