Ciao a tutti, sono alle prese con la progettazione ed architettura del software. Premetto che sono alle prime armi, quindi le mie domande potrebbero sembrarvi banali.
Volevo chiedervi un parere. Sto sviluppando un programma per la gestione di una videoteca casalinga e sto implementando le entità che serviranno per il corretto funzionamento dell'applicazione.
Nel caso specifico, ho la classe Film che espone le proprietà che descrivono l'oggetto (come il titolo, il genere, la durata, ecc...). Stavo pensando di implementare anche i metodi che implementaranno il prestito e la restituzione del film. Il dubbio che mi è sorto è se è il caso di implementarlo nella classe dell'entità oppure è il caso di implementarlo in una classe separata FilmServices.
Ho provato a dare un occhio a progetti come NSK però sono un pò complessi per me che sono newbie in ambito di archiettura del software.
Vi ringrazio anticipatamente.
Marco.
Puoi adottare entrambe le metodologie. Se fai una filmServices adotti un approccio più classico, in cui le entità sono semplicemente dei contenitori per le proprietà che andranno su un database, mentre se doti la classe di metodi propri sei più in ottica domain model, in cui le entità hanno anche i metodi di business.
In entrambi i casi puoi adottare o meno un orm per la persistenza, naturalmente se le classi iniziano ad avere relazioni tra di loro (ad esmepio la classe Film ha una proprietà di tipo Customer che indica se un film attualmente è in prestito o meno etc) è consigliabile un orm, per avere il vantaggio di usare il lazy load e non doverti preoccupare del db. Se gli oggetti sono più disconnessi puòi invece fare un dal classico che si interfaccia con un db.
Non esiste "la soluzione" ma vari approcci differenti, se sei alle prime armi consiglio un approccio lite, per cui magari un dal classico evitando di complicare troppo il tutto con orm e quant'altro.
alk.
--Blog Eng: http://www.codewrecks.com/blogBlog Ita: http://blogs.ugidotnet.org/rgmTwitter: http://twitter.com/alkampfer
Come prima cosa ti ringrazio per la risposta.
Sinceramente sono alla ricerca di consigli in quanto sono alle prime esperienze con la progettazione di applicazioni. In genere ho sempre sviluppato su architetture già definite da altri.
Tu cosa mi consigli? L'applicazione in questione è solamente una mia esercitazione, non ha uno scopo commerciale, quindi posso decidere se percorrere una strada oppure l'altra.
Il mio obbiettivo è capire bene ed imparare a strutturare "a regola d'arte" applicazioni ad n-livelli. Da dove posso partire? Dovo posso trovare documentazione ed esempi "semplici"?
Ho parlato di FilmServices perché ho visto un approccio analogo in NSK (Northwind Starter Kit) di Andrea Saltarello e sto cercando di imparare guardando il suo codice.
Per il momento vorrei evitare ORM tipo NHibernate e Linq2SQL perché vorrei avere una panoramica completa di come strutturare il software.
Una curiosità, sempre nel progetto NSK, ho visto che viene usato il pattern Unit of Work. Ho cercato su Google ma non ho trovato molte informazioni (comprensibili e magari in italiano) su questo pattern. Mi puoi spiegare di cosa si tratta e magari indicarmi qualche esempio per capire quando e come utilizzarlo?
Grazie mille ancora per la risposta e di nuovo buona Pasqua.
Marco
Unit Of Work è un pattern del famoso libro "Pattern of enterprise application architecture" di cui ti consiglio la lettura puoi poi leggere anche il libro di Andrea Saltarello.In italiano non trovi nulla, il consiglio migliore che ti posso dare è quello di fare pratica con i testi in inglese.
Il pattern Unit Of Work comunque è una generica astrazione del concetto di "eseguire una serie di operazioni insieme", tenere traccia in una unitofwork di tutto ciò che deve essere fatto ed eseguire tutte le operazioni in maniera atomica ed in un dato momento. è uno dei pattern standard che sono implementati dagli ORM. Se dovessi vedere un ORM ti sconsiglio Linq2Sql, il suo sviluppo è fermo, guardati Entity Framework.
Per il resto in giro per la rete di informazioni ne puoi trovare tante. Se vuoi partire lite prova ad iniziare a scrivere il tuo DAL, tenendo in considerazione le problematiche di gestione transazione etc. Esponi il tuo dal come servizio e quindi con le varie funzioni tipo
SaveOrUpdateFilm, LoadFilmByxx
Cercando di strutturare bene il tutto, sopra costruiscici uin po di logoca ed una interfaccia minimale. Quando hai finito il tutto e ti sei fatto un po le ossa, magari trova qualcuno con cui confrontarti dicendo "io ho fatto cosi, tu come avresti fatto?" ed intanto inizia tu stesso a rifattorizzare cercando di migliorare la struttura che hai.
Augurissimi anche a te.
L'ho visto il libro di Andrea (l'ha acquistato un mio collega) ma per il momento mi sembra complicato per uno che come me inizia.
Per il momento vi ringrazio, comincio a fare un giro sul web alla ricerca di esempi di come progettare un buon DAL.
Grazie mille di nuovo.
>Divorato in poco meno di una settimana. >Ottima lettura, anche se - Andrea non me ne vorrà - presenta qualche >pecca.
solo "qualche" pecca? WOW, allora tutto sommato mi è andata bene: pensa che ci sono alcune parti che rivedrei di sana pianta :-)
BTW, non vedo l'ora di leggere il feedback
>Ho parlato di FilmServices perché ho visto un approccio analogo in NSK (Northwind Starter Kit) di Andrea Saltarello >e sto cercando di imparare guardando il suo codice.
Ok, aggiungo una tacca alla lista di quelle poste sotto l'etichetta "NSK è sovracomplesso" :-) Scherzi (quali?) a parte, l' "Accademia" dice che il Domain Model dovrebbe contenere la domain logic, mentre nei servizi è contenuta la application logic. Semplificando al massimo, puoi pensare che la domain logic sia quella "quota" di business logic comune a tutti i modi di usare il DM, mente l'application logic sia... Tutto il resto :-) Spesso si dice che la application logic effettui uno "scripting" del DM.
Ecco perchè il metodo CalculateTotalIncome "sta" dentro Customer mentre CalculateSuggestedDiscountRate è definito nel servizio CustomerServices.
Messa da parte l'accademia, però, eccoci nel mondo reale: se hai dubbi, IMHO meglio aggiungere logica ai servizi aumentando l'anemia delle entità. Per quanto "brutto" e "poco OO", è una strategia di design sicuramente (almeno all'inizio) meno prona ad errori e più facile da gestire
.A
Troppi termini "difficili" tutti in una volta sola. Il mio cervello ha fatto tilt... Esiste qualche Web cast o qualche documento che spiega le differenza tra Domain Model, Domain Logic, ecc...?
Ho chiesto al mio collega di prestarmi il tuo libro. Domani provo a leggere il primo capitolo e se riesco a capirlo penso di acquistarlo.
Non ti faccio domande riguardo la tua risposta perché (per colpa mia) sinceramente sono ancora un pò confuso. Devo fermarmi e rileggerla qualche volta... :-) chiedo solamente 3 cose:
Grazie mille.