Pagina 2 di 4 primaprima 1 2 3 4 ultimoultimo
Visualizzazione dei risultati da 11 a 20 su 36
  1. #11

    Re: Re: Re: Re: Re: Re: Applicazione n-tier ho letto miiiiiille esempi e ci ho provato ... mi restan

    Originariamente inviato da naighes
    Spero di esserti stato di aiuto.
    ma grazie... in una "vera" applicazione le cose sono diverse. Ad esempio non fai i vari livelli mettendoli tutti in una unica dll e stai attento alla visibilita' degli oggetti e cosi via. Il problema non sarebbe tanto che il tizio del frontend vedrrebbe o no un unico punto d'accesso come dici tu ma che ogni modifica al cosidetto livello determina una ricompilazione di tutto.
    All'interno del pattern
    UI->Manager->XXXDal->DB
    poi possiamo metterci dentro gli altri design pattern
    Peraltro, ogni entity del modello puo' essere di uno stesso tipo (es. classe base o interfaccia come hai fatto l'esempio tu) ma poi il dal che torna gli oggetti, dovrebbe tornare gli oggetti del tipo giusto altrimenti costringi ad usare cast su cast nella business logic
    Saluti a tutti
    Riccardo

  2. #12
    Originariamente inviato da Valeria75_bis
    Grazie a tutti per l'aiuto!
    Figurati!

    Originariamente inviato da Valeria75_bis
    Cosa intendi per "arricchirle" in
    << Per quello che riguarda le Entity e le Collection credo che tu sia sulla strada giusta, anche se credo che dovresti ulteriormente arricchirle. >>
    Che puoi aggiungere altre proprietà e metodi.
    Per le collection, ad esempio, potresti implementare la logica per l'ordinamento.
    Le Entities, invece, dovrebbero tutte implementare un'interfaccia comune, all'interno della quale definisci le caratteristiche che ciascuna Entity deve possedere.
    Per cominciare, comunque, va benissimo come hai fatto tu (almeno per ciò che concerne Entities e Collections).

    Originariamente inviato da Valeria75_bis
    Quindi anche cosi va bene, ma un esempio di quello che potrei inserire (in futuro) in questa collection quale potrebbe essere?
    L'ordinamento, come ti ho detto sopra, oppure qualche metodo che ti consenta di filtrare la collezione.
    Esempio:

    codice:
    public class WebUtenteCollection : Collection<WebUtente>
    {
    	public WebUtenteCollection Select(DateTime subscriptionDate)
            {
    		WebUtenteCollection items = new WebUtenteCollection();
                		foreach (WebUtente item in base.Items)
                    		if (item.StartDate.Equals(subscriptionDate))
                        			items.Add(item);
    
                	return items;
            }
    }
    Originariamente inviato da Valeria75_bis Cosa intendi per "casi speciali"?
    Intendo che dovresti definire della classi speciali che evitino riferimenti a null.
    Esempio:

    codice:
    public class UnknowWebUtente : WebUtente
    {
    	public UnknowWebUtente()
    	{
    		base.ID = -1;
    	}
    }
    All'interno del metodo Read(params object[] identifiers) della classe WebUtenteData, restituirai l'oggetto in questione nel caso in cui si siano verificati degli errori o nel caso in cui l'utente non venga trovato.

    Originariamente inviato da Valeria75_bis Ma nell'esempio che ho trovato c'era proprio questa WebUtentiManager... quello che vorrei capire è quello che dovrei inserire qui dentro :-(( (anche per il futuro, quando la logica si complicherà)
    Probabilmente c'era (e sarebbe stato un male non ci fosse stata), ma sei sicura che sia stata utilizzata come hai scritto tu? (non credo...)
    Per il resto, rileggiti i miei post precedenti.

    Spero di esserti stato di aiuto.
    Nicola Baldi <% Naighes %>
    Il mio blog!

    "Non hai veramente capito qualcosa fino a quando non sei in grado di spiegarlo a tua nonna."

  3. #13
    Utente di HTML.it
    Registrato dal
    Jul 2006
    Messaggi
    3,072
    Quindi, anche alla luce della vostra discussione,

    WebUtentiManager

    come dovrei gestirla correttamente? la elimino oppure posso usaral per gestire ....cosa?

    ultima info:

    ho cercato ma non ho trovato nessun esempio di sorgente della classe sqlHelper ... sapreste dirmi dove posso trovarla??

    Grazie

  4. #14
    Originariamente inviato da riccardone
    in una "vera" applicazione le cose sono diverse.
    Beh, a me sembrava che Valeria avesse chiesto come strutturare un'applicazione, o no?

    Originariamente inviato da riccardone
    Ad esempio non fai i vari livelli mettendoli tutti in una unica dll e stai attento alla visibilita' degli oggetti e cosi via.
    No, aspetta, non ho mai ha parlato di utilizzare un singolo assembly.
    Stiamo parlando della suddivisione della logica, i cui strati non sempre coincidono con il numero di assembly.

    Originariamente inviato da riccardone
    Il problema non sarebbe tanto che il tizio del frontend vedrrebbe o no un unico punto d'accesso come dici tu ma che ogni modifica al cosidetto livello determina una ricompilazione di tutto.
    Il concetto dell'unico punto di accesso è proprio la base della logica che ti consente di svincolarti dai livelli sottostanti.
    Il quesito, quindi, rimane lo stesso.
    Se il sig. Rossi ti chiede quale classe deve utilizzare, tu cosa rispondi?
    Che senso ha avere due metodi che fanno esattamente la stessa cosa?
    Perchè dovrei prediligere l'utilizzo di uno rispetto all'altro.
    E' questo che mi chiedo.

    Originariamente inviato da riccardone
    All'interno del pattern
    UI->Manager->XXXDal->DB
    poi possiamo metterci dentro gli altri design pattern
    Peraltro, ogni entity del modello puo' essere di uno stesso tipo (es. classe base o interfaccia come hai fatto l'esempio tu) ma poi il dal che torna gli oggetti, dovrebbe tornare gli oggetti del tipo giusto altrimenti costringi ad usare cast su cast nella business logic
    Non vedo cosa ci sia di male ad effettuare un cast all'interno della Business Logic.
    A mio modesto avviso (e non solo), in termini di riusabilità del codice la soluzione che ti ho mostrato qualche post addietro è nettamente superiore rispetto all'approccio che ha mostrato Valeria.

    Come ho indicato precedentemente, dovresti scaricarti questo esempio:
    http://www.dotnetcircle.it/demo/fire...House.Code.zip

    Quì, invece, viene spiegato, a grandi linee, il tipo di approccio.
    http://blogs.aspitalia.com/rickyvr/p...oniFaremo.aspx

    Sono esempi un pò vecchiotti, ma di un'attualità incredibile.
    Prova a dare un'occhiata ai link che ti ho indicato e magari ne possiamo discutere in questa sede.

    Spero di esserti stato di aiuto.
    Nicola Baldi <% Naighes %>
    Il mio blog!

    "Non hai veramente capito qualcosa fino a quando non sei in grado di spiegarlo a tua nonna."

  5. #15
    Utente di HTML.it
    Registrato dal
    Jul 2006
    Messaggi
    3,072
    Modifico il mio quesito precedente


    Quindi, anche alla luce della vostra discussione,

    WebUtentiManager

    come dovrei gestirla correttamente? la elimino oppure posso usarla per gestire alcuni metodi relativi agli utenti....cosa (un esempio di cosa potrei gestire in questa classe mi chiarirebbe molto le idee)?

    ultima info: (modificato rispetto al post precedente)

    ho provato ad utilizzare la classe sqlHelper postata nella discussione ... c'è un piccolo problemi nella definizione di sqlParams ... ma non capisco come sistemarla

    Grazie

  6. #16
    Originariamente inviato da naighes
    Beh, a me sembrava che Valeria avesse chiesto come strutturare un'applicazione, o no?
    aspetta.. riassiumiamo.. un conto e' chiedere di spiegare "a grandi linee" i layer applicativi e un conto e' scendere nel dettaglio per dire di usare una interfaccia es. IEntity e/o una classe sealed ecc. ecc..

    Il concetto dell'unico punto di accesso è proprio la base della logica che ti consente di svincolarti dai livelli sottostanti.
    Il quesito, quindi, rimane lo stesso.
    Se il sig. Rossi ti chiede quale classe deve utilizzare, tu cosa rispondi?
    ...la classe manager. Se poi lui si impunta e si crea il suo manager per riutilizzare il dal non posso farci niente ma non e' questo il punto.

    Che senso ha avere due metodi che fanno esattamente la stessa cosa?
    Perchè dovrei prediligere l'utilizzo di uno rispetto all'altro.
    E' questo che mi chiedo.
    Dovresti dirmi dove l'esempio iniziale presenta due metodi che fanno la stessa cosa nello stesso modo. Uno usa l'altro.
    Come ho gia' detto all'inizio, la business logic puo' ridursi semplicemente a richiamare metodi simili nel livello sottostante del dal. In gergo viene chiamata la business logic "anemica". Parte della logica viene risucchiata dall'eventuale strato di web service sopra e parte della logica viene risucchiata dal data access layer sotto. Non per questo bisogna togliere valore alla business logic o pensare di utilizzare direttamente il dal.

    Non vedo cosa ci sia di male ad effettuare un cast all'interno della Business Logic.
    A mio modesto avviso (e non solo), in termini di riusabilità del codice la soluzione che ti ho mostrato qualche post addietro è nettamente superiore rispetto all'approccio che ha mostrato Valeria.
    cosa vuol dire "cosa ci sia di male ad effettuare un cast all'interno della Business Logic" ? E' evidente che di male ci sono tante belle castexception che ti salterebbero in faccia a runtime nel caso sbagliassi qualcosa. Per correggere questo potenziale problema, basterebbe che fai tornare direttamente il tipo giusto al metodo nel dal anche se quel tipo eredita da un tipo comune a tutte le entity.

    Come ho indicato precedentemente, dovresti scaricarti questo esempio:
    http://www.dotnetcircle.it/demo/fire...House.Code.zip
    quell'esempio io, come tutti quelli che seguono con attenzione le iniziative della community es. ugidotnet aspitalia ecc. ecc., lo conosco bene. Peraltro, ti consiglio di usare non quello ma semmai quello piu' aggiornato presente su sourceforge e che prende come base dati il db northwind.

    Sono esempi un pò vecchiotti, ma di un'attualità incredibile.
    incredibile forse possono esserlo per chi li scopre ora. Anzi, per chi e' a digiuno di oop e di design pattern piu' che incredibile possono apparire un incubo in quanto quell'architettura (che e' universalmente riconosciuta come una delle piu' valide) porta ad una ploriferazione anzi "esplosione" di librerie, di classi e di interfacce. Io ho applicato quel modello a molte delle applicazioni che ho sviluppato e ti assicuro che quando ci si sposta da casi teorici e si va su applicazioni concrete aggiungere nuovi dal, modificare svariate librerie per ogni modifica e cercare di implementare anche sistemi per la gestione della concorrenza non e' una passeggiata.
    Quindi, ho sempre sperato di trovare un pattern architetturale meno elefantiaco dell'abstract factory. Pensavo di approfondire la possibilita' di usare il pattern Provider ma ora ho deciso di aspettare l'uscita di linQ perche' credo che alleggerira' molto il lavoro.

    Spero di esserti stato di aiuto.
    Saluti a tutti
    Riccardo

  7. #17
    ecco il link per chi puo' essere interessato al northwind starter kit
    http://sourceforge.net/projects/nsk/
    Saluti a tutti
    Riccardo

  8. #18
    Originariamente inviato da riccardone
    ...la classe manager.
    Bene, e lui ti chiederà: "Perchè? Se utilizzo direttamente il DAL mi cambia qualcosa?"

    Originariamente inviato da riccardone Dovresti dirmi dove l'esempio iniziale presenta due metodi che fanno la stessa cosa nello stesso modo. Uno usa l'altro.
    Non capisco, per quanto possano farlo in modo diverso, a me che scrivo il Front-End applicativo non me ne può fregar di meno.
    Io voglio la collezione di oggetti WebUtente, non mi interessa sapere che un metodo lo fa in un modo e quello di un'altra classe in un altro.
    Al DAL non devo poterci accedere direttamente, questo è il punto.
    Ci vuole quindi un Entry Point, che è rappresentato dalla Business Logic.

    Originariamente inviato da riccardone
    In gergo viene chiamata la business logic "anemica". Parte della logica viene risucchiata dall'eventuale strato di web service sopra e parte della logica viene risucchiata dal data access layer sotto. Non per questo bisogna togliere valore alla business logic o pensare di utilizzare direttamente il dal.
    Non ho capito, le chiamate dal webservice le effettui direttamente sul DAL?
    O forse ho capito male?
    In ogni caso, non capisco perchè mi chiedi di dar valore alla Business Logic se il già il DAL
    mi fornisce membri pubblici che forniscono gli stessi risultati di una chiamata effettuata all'interno della Business Logic.
    Scusa, ma questo proprio non lo capisco.

    Originariamente inviato da riccardone cosa vuol dire "cosa ci sia di male ad effettuare un cast all'interno della Business Logic" ? E' evidente che di male ci sono tante belle castexception che ti salterebbero in faccia a runtime nel caso sbagliassi qualcosa. Per correggere questo potenziale problema, basterebbe che fai tornare direttamente il tipo giusto al metodo nel dal anche se quel tipo eredita da un tipo comune a tutte le entity.
    Sbagli.
    Innanzitutto è auspicabile l'utilizzo di un pattern per l'exception handling, e poi di eccezioni non ne possono venire fuori, perchè è proprio la Business Logic che si occupa di restituire il tipo corretto (possono venir generate dalla Business Logic quanto dal DAL, non trovi? E poi, almeno un test di integrità lo vorremo far superare alla nostra applicazione prima di distribuirla! ).

    Originariamente inviato da riccardone
    incredibile forse possono esserlo per chi li scopre ora. Anzi, per chi e' a digiuno di oop e di design pattern piu' che incredibile possono apparire un incubo in quanto quell'architettura (che e' universalmente riconosciuta come una delle piu' valide) porta ad una ploriferazione anzi "esplosione" di librerie, di classi e di interfacce. Io ho applicato quel modello a molte delle applicazioni che ho sviluppato e ti assicuro che quando ci si sposta da casi teorici e si va su applicazioni concrete aggiungere nuovi dal, modificare svariate librerie per ogni modifica e cercare di implementare anche sistemi per la gestione della concorrenza non e' una passeggiata.
    Quindi, ho sempre sperato di trovare un pattern architetturale meno elefantiaco dell'abstract factory. Pensavo di approfondire la possibilita' di usare il pattern Provider ma ora ho deciso di aspettare l'uscita di linQ perche' credo che alleggerira' molto il lavoro.
    L'incredibile era riferito all'attualità del modello, non alla difficoltà della sua implementazione.
    Quello che volevo segnalarti era semplicemente ciò che ti ho detto sopra, ovvero l'assoluta e insindacabile inutilità della Business Logic mostrata da Valeria.

    Poi, certamente, esistono altri modelli, e di questo ne possiamo discutere.
    Nicola Baldi <% Naighes %>
    Il mio blog!

    "Non hai veramente capito qualcosa fino a quando non sei in grado di spiegarlo a tua nonna."

  9. #19
    Originariamente inviato da naighes
    Bene, e lui ti chiederà: "Perchè? Se utilizzo direttamente il DAL mi cambia qualcosa?"
    e tu gli risponderai: si, se chiami il dal non ti assicuro niente se si spacca qualcosa. E tu saprai dentro di te che oggi e' la stessa cosa. Domani, quando lui ti chiedera' di arricchire la collection di clienti con anche gli ordini, potrai gestire tutto a livello di business logic senza obbligarlo a fare lavoro inutile a livello di front end. Domani, quando avrai 2 dal uno per ogni db, potrai mettere delle regole sulla data di nascita dei clienti una volta sola nella business logic e non sdoppiando la regola nel dal o nel db.

    Non capisco, per quanto possano farlo in modo diverso, a me che scrivo il Front-End applicativo non me ne può fregar di meno.
    Io voglio la collezione di oggetti WebUtente, non mi interessa sapere che un metodo lo fa in un modo e quello di un'altra classe in un altro.
    Al DAL non devo poterci accedere direttamente, questo è il punto.
    Ci vuole quindi un Entry Point, che è rappresentato dalla Business Logic.
    E dalla con sto entry point. Se l'amico che fa il front end vuole usare il dal puo' farlo anche se scrivi sealed o protected con qualche artifizio. E' giusto usare correttamente la visibilita' degli oggetti, ma la regola deve essere quella di usare il domain model attraverso le classi manager e non quelle del dal.

    Non ho capito, le chiamate dal webservice le effettui direttamente sul DAL?
    O forse ho capito male?
    direi che hai capito male, forse mi sono spiegato male io. Se passiamo ad una architettura soa possiamo aggiungere il livello ws cosi
    UI->WS->Manager->XXXDal->DB

    In ogni caso, non capisco perchè mi chiedi di dar valore alla Business Logic se il già il DAL
    mi fornisce membri pubblici che forniscono gli stessi risultati di una chiamata effettuata all'interno della Business Logic.
    Scusa, ma questo proprio non lo capisco.
    Per varie ragioni. Una ad esempio e' quella di evitare di essere costretti a sdoppiare regole e/o creazione di collection o oggetti arricchiti con altre collection o oggetti. Un'altra e' quella di facilitare anche in un secondo momento l'aggiunta di nuovi dal.

    Sbagli.
    Innanzitutto è auspicabile l'utilizzo di un pattern per l'exception handling, e poi di eccezioni non ne possono venire fuori, perchè è proprio la Business Logic che si occupa di restituire il tipo corretto (possono venir generate dalla Business Logic quanto dal DAL, non trovi? E poi, almeno un test di integrità lo vorremo far superare alla nostra applicazione prima di distribuirla! ).
    mi sono un attimo perso. Chi e' che raccoglie le eccezioni? Una eccezione, e' buona regola salti nel musetto del primo che inizia la chiamata es. il front end. Eventualmente nel mezzo possiamo decidere di loggare informazioni, spedire mail con i dettagli, cambiare il messaggio o chissa cos'altro. Se l'eccezione sollevata nel dal o nella business logic si ferma li, l'utente nel front end avra' il classico comportamento del click sul pulsante senza che succeda nulla.
    Detto questo, se chiedo al dal una collection di oggetti di tipo Cliente voglio avere una collection di oggetti di tipo Cliente e non di tipo IContractblabla. Non voglio dover castare un bel nulla altrimenti invece dei generics e del mondo strong typed in cui per fortuna siamo tanto vale mettere tutto in una hashtable e fare il cast nella business logic da object.
    Utilizzare un tipo comune (interfaccia o classe base) per tutte le entity e' una ottima cosa e permette di uniformare il comportamento delle entita' del domain model.


    ciò che ti ho detto sopra, ovvero l'assoluta e insindacabile inutilità della Business Logic mostrata da Valeria.
    puoi anche ridirmelo in maniera "assoluta e insindacabile" ma ti ripeterei quanto detto sopra.
    Saluti a tutti
    Riccardo

  10. #20
    Utente di HTML.it
    Registrato dal
    Jul 2006
    Messaggi
    3,072
    Mi intrometto ... qualcuno potrebbe gentilmente chiarirmi questi due dubbi:

    Quindi, anche alla luce della vostra discussione,

    WebUtentiManager

    come dovrei gestirla correttamente? la elimino oppure posso usarla per gestire alcuni metodi relativi agli utenti....cosa (un esempio di cosa potrei gestire in questa classe mi chiarirebbe molto le idee)?

    ultima info: (modificato rispetto al post precedente)

    ho provato ad utilizzare la classe sqlHelper postata nella discussione ... c'è un piccolo problemi nella definizione di sqlParams ... ma non capisco come sistemarla

    Grazie

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2026 vBulletin Solutions, Inc. All rights reserved.