Newsgroup: it.comp.dotnet
Titolo: Gestire metodi di ricerca in funzione delle impostazioni dell'operatore

Ciao a tutti,
programmo in visual c# 2005 e volevo porre quesito per una corretta 
impostazione di programmazione:
Vi spiego il mio problema:
Su un'applicazione desktop gestita con logica 3 Tier che attinge i dati 
da un db Sql Server,
ho una maschera di ricerca il cui risultato è un list di miei oggetti 
che vengono elencati su una datagridview.
Vengo al punto:
Supponiamo che l'operatore possa ricercare per :
Anno
Denominazione
Citta
Al comando 'TROVA', dell'operatore sulla mascherina deve essere eseguita 
una funzione Find dove passo i parametri di ricerca impostati 
dall'operatore.
C'è un modello da seguire per la gestione di ricerca ?
Mi spiego:
Nella classe gestione quante Find devo implementare ?
Find(anno)
FInd(anno, Denominazione)
Find(anno, Citta)
Find(Denominazione, Citta)
Ovviamente per ciascuna Find poi devo creare il suo omonimo nella parte 
Dal per poi ricostruire la query da dare in pasto a Sql Server.
Non so se ho reso l'idea.
Ricerco documentazione in tal senso.
Thanks.

 Thanks.
.m
-- 
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com/profile/mauro
blog @ 
http://milestone.topics.it
whynot [ at ] topics [ dot ] it

 }
Ti ringrazio di avere risposto al mio problema: Hai ragione
non sono stato molto chiaro nello spiegare il tutto.
Ho un paio di domande sulla tua risposta:
Intanto ti chiedo dove devo dichiarare l'interfaccia ?
Lato business object ?
Io non sono abituato ad utilizzare le interfacce e questo codice mi 
spiazza un pò.
Cmq. voglio capire meglio.
Mi spieghi meglio dall'interfaccia utente fino alla Dal ?
Diciamo in modo schematico, dove si infila questa interfaccia nello 
schema sotto ?
View----------------------> Business Logic ------------------> Dal
es.nel caso lineare: L'operatore ricerca per Anno.
View --> Gestione gest= new Gestione();
          List<mio_oggetto> elenco = gest.Find(Anno);
Business Logic-->   Class Gestione
                     Dal db= new Dal();
                     List<mio_oggetto> dati= db.Find(_anno);
Dal            -->  Class Dal
                     metodo TrovaDb(int anno);
                     metodo TrovaDb(int anno, Azienda az);
                     ...
                     ...
Thanks

 Lato business object ?
Io opterei per una cosa del genere:
http://martinfowler.com/eaaCatalog/queryObject.html
In sostanza dichiari un oggetto che rappresenta una query, come ha 
suggerito Mauro con l'oggetto Criteria. Nella tua view, fai editare 
l'oggetto all'utente e poi lo passi al servizio di business che 
orchestra le chiamate al data layer "interpretando" l'oggetto Criteria.
HTH,
Giulio
-- 


Ho capito questi punti e vi ringrazio.
Approfitto della vostra bontà per chiedervi perchè è utile l'utilizzo di
interface ISearchEngine
{
IEnumerable<Result> Search( Criteri criteri );
}
e poi chi deve ereditare questa interfaccia ?
Il Dal o la business logic ?
E' corretto scrivere cosi ?
  public class Dal:ISearchEngine
     {
         public List<Result> Search(Criteri criteri)
         {
             List<Result> elenco = null;
             return elenco;
         }
     }
Grazie e buon lavoro.

 Grazie e buon lavoro.



Mi che sei ermetico: Speravo in qualcosa di + concreto.
Comunque grazie e buona continuazione.

Ciao Romano,

potrei farci un corso di 3 giorni su un argomento del genere :-P
Cerca "dependency injection" e "inversion of control".


 potrei farci un corso di 3 giorni su un argomento del genere :-P
Ok, se lo fai fammi un fischio. :-)
Scherzi a parte, per come l'ho messa io, l'interfaccia andrebbe fatta 
ereditare dal business layer per una questione pratica. La definizione 
della classe che implementa il criterio deve essere visibile nel 
presentation layer che "vede" il bsuiness layer. Implementare il tutto 
nel DAL significherebbe dover inserire questa dipendenza (DAL -> BL) che 
dovrebbe essere risolta con una cosa tipo separated interface (i.e. 
estraendo la definizione dei criteri in un ulteriore assembly/componente 
visibile da tutti). Ora, 'sta cosa mi darebbe non poca noia... :) quindi 
io impementerei l'interfaccia per la ricerca come servizio di business.
Detto questo, va comunque detto che Mauro ha ragione e che l'argomento 
non è facilmente risolvibile con un "fai così". Quella che ho proposto 
io è *una* soluzione, non è detto che sia la migliore né tantomeno 
quella più adatta al tuo caso. Può comunque essere un punto di partenza.
buon lavoro e facci sapere come va a finire,
Giulio
-- 

 ricerca come servizio di business.
condivido.
