Salve a tutti,
Sto progettando un sistema per un progetto universitario, quindi come progettista sono ancora decisamente inesperto
Prima di buttarmi a capofitto nella stesura del codice, dopo aver concluso la parte relativa all'analisi, naturalmente ci sono da prendere alcune cruciali decisioni progettuali, quali ad esempio lo stile architetturale... allora giù a documentarmi (il corso che ho seguito "promuoveva" per lo più il three-tier), adesso sono indeciso tra 3-tier e MVC, che per certi versi trovo molto simili.
Il problema è che forse non mi è chiara una cosa:
fermorestando che l'intento è quello di produrre un sistema che sia il più corretto possibile dal punto di vista ingegnieristico e quindi quello di separare il più possibile la logica di presentazione da quella di business ed incapsulare l'accesso ai dati in un layer o una componente separata, ho un dubbio atroce dal quale non riesco a venirne a capo.
I dati che dovrò visualizzare nelle View (o almeno in alcune) saranno per forza di cose prelevati dal Model. Ma allora come è possibile tenere realmente separati i livelli?
O meglio, so come rendere il mio Model completamente separato da tutto il resto (il che è già un bene).
L'idea è quella di implementare nel Model delle interfacce stabili (in lettura e scrittura) per prelevare i dati dal DB e costruire le classi entity. Dite che va bene come approccio?
Ad esempio, l'interfaccia in lettura per ottenere i dati di un Paziente dal DB conterrà i seguenti metodi:
Ora, la View in cui visualizzare l'elenco dei pazienti o modificare un paziente dovrà per forza di cose conoscere la struttura della classe entity Paziente (che è sostanzialmente una semplice classe POJO, con i metodi getter e setter... praticamente è un transfer object, no?).codice:public Paziente getPazienteById(int id); public Vector<Paziente> getAllPazienti();
In questo modo la View sarà accoppiata al Model e non vedo modo di evitare tale accoppiamento, dal momento che per raggiungere il suo scopo la view deve conoscere i dati da visualizzare e quindi la loro struttura (altrimenti cosa visualizzo?).
Anche se non volessi far comunicare direttamente le View con il Model, avrei due alternative:
1. un Controller richiede i dati al Model (tramite ad esempio getPaziente()) e passa la classe Paziente alla View.
In questo caso sarei al punto di partenza (View accoppiata al Model in quanto deve conoscere i dettagli della classe Paziente), ma ho solo un passaggio addizionale tramite il controller; in pratica mi sembra di utilizzare l'architettura 3-tier anziché MVC, è corretto?
2. un Controller richiede i dati al Model e passa alla View i singoli attributi che la compongono.
Penso che questo in realtà significhi semplicemente aggirare il problema: ad ogni modo la View dovrà conoscere la struttura della classe (nel senso che saprà che il ha un id di tipo int, un nome di tipo String, etc), l'unica cosa che perderà è il riferimento alla stessa... ma ha effettivamente un senso fare questa cosa? Tanto vale passare la classe no?
Perché il problema è sempre e solo uno: nel caso in cui la classe cambi (ed effettivamente lo farà a causa di un cambiamento dei requisiti iniziali), ad esempio modificando il campoincodice:String Cellulare;sarò costretto a modificare:codice:Vector<String> Cellulare;
1) lo schema del DB
2) la classe che implementa le interfacce in lettura e scrittura dei Pazienti
3) la classe entity Paziente
4) tutte le view relative ai Pazienti.
E sinceramente temo che tutti questi cambiamenti siano un po' troppi e siano indice di un progetto fatto male.
Ce'è un modo per rendere la soluzione più ingegneristica?
Please Help!!
Rispondi quotando
