tdusko @ 04.07.2008. 21:19
Radim seminarski rad na temu paterna. Rad se sastoji od web aplikacije u kojoj trebam implementirati neki od paterna i dokumentacije u kojoj trebam da opisem te paterne koje sam koristio. Problem koji imam sastoji se u tome da sam ja napisao aplikaciju ali ne znam koje sam sve paterne koristio. Ja cu sada napisati kod u kome mislim da se moze prepoznati neki patern. Nadam se da ce se neko zainteresovati da mi pomogne

Rad sa metodama za rad sa bazom podataka uvek radim na isti nacin. Imam klasu OpstiManager koja ima genericke metode za Insert, Update, Delete. Evo metode za insert:

Code:

 protected void CreateObject(int PrimaryKey, DataTable Attributes)
        {
            try
            {
                string aTableName = Attributes.TableName;

                SqlCommand aCommand = broker.CreateCommand();

                string sqlQuery = "INSERT INTO " + aTableName + " (" + aTableName + "ID, ";
                foreach (DataRow row in Attributes.Rows)
                    sqlQuery += row["Name"].ToString() + ", ";

                sqlQuery = sqlQuery.Remove(sqlQuery.Length - 2);
                sqlQuery += ") VALUES (";
                sqlQuery += broker.FormatParameterName(aTableName + "ID, ");
                foreach (DataRow row in Attributes.Rows)
                    sqlQuery += broker.FormatParameterName(row["Name"].ToString()) + ", ";

                sqlQuery = sqlQuery.Remove(sqlQuery.Length - 2);
                sqlQuery += ") ";

                aCommand.CommandText = sqlQuery;

                broker.AddInputParameter(aCommand, aTableName + "ID", DbType.Int32, PrimaryKey);
                foreach (DataRow row in Attributes.Rows)
                    broker.AddInputParameter(aCommand, row["Name"].ToString(),
                        (DbType)row["DbType"], row["Value"]);

                aCommand.ExecuteNonQuery();
            }
            catch (Exception ex)
            {
                throw ex;
            }
        }


Za svaki objekat pravim po jednog managera koji nasledjuje klasu opstiManager i u njemu imam metode za insert, update, delete koje samo pripreme ulazne argumente za iste te metode opstegManagera i pozivaju metodu opsteg managera. Na primer klasa koja radi sa evidencijama ima metodu AddEvidence:

Code:

  public string AddEvidence(string SifraKorisnika, DateTime DatumEvidencije, int Glava, DataTable Stavke)
        {
            try
            {             
                DataTable Evidencija = MasterManager.CreateAttributesTable("tblEvidencija");
                string BrojEvidencije = GetEvidenceNumnber(Glava);
                Evidencija.Rows.Add(new object[] { "BrojZahteva", BrojEvidencije, DbType.String });
                Evidencija.Rows.Add(new object[] { "SifraKorisnika", SifraKorisnika, DbType.String });
                Evidencija.Rows.Add(new object[] { "DatumPredajeZahteva", DatumEvidencije, DbType.DateTime });
                Evidencija.Rows.Add(new object[] { "Glava", Glava, DbType.Int32 });

                CreateObjectPK(Evidencija);


                foreach (DataRow Stavka in Stavke.Rows)
                {
                    int RedniBr = Convert.ToInt32(Stavka["RedniBr"]);
                    string Opis = Stavka["Opis"].ToString();
                    string KontoKorisnika = Stavka["KontoKorisnika"].ToString();
                    string TransferniKonto = Stavka["TransferniKonto"].ToString();
                    double Iznos = Convert.ToDouble(Stavka["Iznos"]);

                    AddEvidenceItem(RedniBr, BrojEvidencije, Opis, TransferniKonto, KontoKorisnika, Iznos, 1);
                }


                return BrojEvidencije;
            }
            catch (Exception ex)
            {
                throw ex;
            }
        }


Da li ovo moze biti mozda Adapter patern?

[Shadowed: dodati code tagovi.]

[Ovu poruku je menjao Shadowed dana 04.07.2008. u 23:18 GMT+1]
mmix @ 05.07.2008. 08:49
Da krenemo redom:

1. imas broker objekat, ali on definitivno nije entry u broker pattern. Broker sluzi da apstraktuje implementaciju nekog distributed layera/servisa enakpsulirajuci taj layer/service u poseban sloj van BL-a. Ti koliko vidim tu jednostavno kreiras SqlCommand objekat i pretpostavljam inicijalizujes connection, sto nema nikakve veze sa broker patternom, pogledaj ovaj link: Broker Pattern

2. Nacin na koji baratas podacim high-level malo podseca na DTO (Data Transfer Objects), mada u tu svrhu koristis DataTable kao nosioca podataka sto bas i nije u duhu tog patterna, namena DTO patterna je da se konvezija iz "skupog" u "jeftiniji" data model obavi samo jedanput da bi se svaki naknadni pristup podacima obavi sa minimalnim uticajem na performanse. Da bi imao DTO pattern (mozes ga naci u starijoj literaturi i kao VO pattern, ili Value Object pattern), objekti ne mogu imati nikakvu dodatnu funkcionalnost sem citanja i pisanja sopstvenih podataka (sto DataRow i DataDatble ne zadovoljavaju) i tvoji objekti moraju biti deklarisani kao klase sa cistim propertijima, eventualno sa nekim BL pravilima utisnutim u set accessore ili metode tih klasa u kom slucaju se DTO pretvara u Business Objects (BO) pattern, sto ti takodje names kao deo DataRow/Table.

3. Tvoj opstiManager i njegovi naslednici zadovoljavaju DAO (Data Access Objects) pattern, pod uslovom da korisnici tih klasas vise ne brljaju sami po bazi (taj kod nisi okacio).

4. Adapter pattern, to je vec diskutabilno. Iako tvoj DAO podseca na DataAdapter, to nije samo po sebi Adapter pattern. Adapter pattern sluzi da se napravi proxy objekat/klasa koji ce jednu implementaciju (adaptee) da prilagodi ocekivanjima klijenta tako da se promene interfejsa/implementacije adaptiranog objekta resava u proxy-u a ne u pozivnom objektu. Kazem da je diskutabilno jer sam po sebi Adapter pattern ne znaci mnogo, ako cemo tako vecina objekata poziva druge objekte koji pozivaju trece objekte i to je kao Adapter pattern . U principu adapter je deo vecih paterna koji se oslanjaju na apstrakciju koju on nudi.
Npr ako tvoja klasa 'Pera' moze da ucitava podatke iz vise izvora (npr xml file, poziv veb servisa i ucitavanjem iz baze) imas dve opcije: a) da Pera sadrzi posebne metode i kod za ucitavanje iz svih tih izvora b) da implementiras Adapter pattern i napravis tri klase koje implementiraju isti interfejs koji Pera razume (npr ima metod Load()) a svaka od te tri klase ima implementaciju koja resava ucitavanje za sebe (prva koristi XmlDocument, druga poziva web servis, treca korisiti DAO da ucita iz baze), sa stanovista Pere on samo instancira odgovarajuci adapter i pozove Load() i ne mora da brine o tome ste je u tom Load-u.




tdusko @ 05.07.2008. 09:16
Jako lepo objasnjeno, nema sta. 100% mi je sada jasno zasto moj kod nije adapter patern i sta trebam da uradim da bi zadovoljio DAO patern.
mmix @ 05.07.2008. 10:19
AKo je za skolski rad ja bih ti preporucio jos jedan korak.

Kad radis sa naslednicima opsteg menager-a nemoj koristiti DataTable. Umesto toga koristi svoje klase koje si napravio npr za Evidenciju koristi klasu Evidencija koja ima svoje propertije od kojih je jedan nix StavkaEvidencije[], a menadzer za evidenciju prilagodis da podatke uzima iz instanci tih klasa a ne iz DataTable/Row. Nije mnogo posla a moci ces onda da kazes da tvoj kod implementira DTO pattern.

Ako te tabele koristis za prikaz u UI-u, uvek niz objekata mozes da konvertujes u List<T> koristeci ToList<T>() metod, a takva lista moze da se binduje na vizulene kontrole, samim tim ti ne treba DataTable i na tom nivou.
mmix @ 05.07.2008. 10:43
I jos jedan predlog. Taj broker (preimenuj ga da ne bi provocirao pitanja), umesto sto koristis neko polje ili slicno, implementiraj npr DataContext klasu kao Singleton pattern. Singleton pattern je veoma jednostavn za implementaciju i u relanom zivotu ga ne bi koristio na tom mestu, ali je za skolski rad je super ;) TO ce ti dati ukupno tri patterna u seminarskom, valjda ce ti to biti dosta za dobru ocenu. Primere singleton patterna u c#-u imas svuda po netu
tdusko @ 05.07.2008. 11:39
Ako sam dobro razumeo predlazes mi da napravim klasu Evidencija koja bi izgledala ovako:


Code:

public class Evidencija : IOpstiDomenskiObjekat
    {
        #region Polja i svojstva

        private int evidencijaId;
        public int EvidencijaId
        {
            get { return evidencijaId; }
            set { evidencijaId = value; }
        }

        private int sifraKorisnika;
        public int SifraKorisnika
        {
            get { return sifraKorisnika; }
            set { sifraKorisnika = value; }
        }

        private string datumPredaje;
        public string DatumPredaje
        {
            get { return datumPredaje; }
            set { datumPredaje = value; }
        }
        private List<StavkeEvidencije> stavkeEvidencije;
        public List<StavkeEvidencije>StavkeEvidencije
        {
            get { return stavkeEvidencije; }
            set { stavkeEvidencije = value; }
        } 

        #region Konstruktori

        #endregion

        public Evidencija()
        {

        }

        public Evidencija(int evidencijaId)
        {
            this.evidencijaId = evidencijaId;
        }

        public Evidencija(int evidencijaId, int sifraKorisnika, string datumPredaje)
        {
            this.evidencijaId = evidencijaId;
            this.sifraKorisnika = sifraKorisnika;
            this.datumPredaje = datumPredaje;
        }


       

        #region IOpstiDomenskiObjekat Members

        public string ImeObjekta
        {
            get { return "Evidencija"; }
        }

        public string ImeKljucnogAtributa
        {
            get { return "EvidencijaId"; }
        }

        public string UslovZaNalazenjeSloga
        {
            get { return "EvidencijaId = " + this.EvidencijaId.ToString(); }
        }

        public string VrednostiAtributaZaAzuriranje
        {
            get
            {
                return " sifraKorisnika= '" + this.sifraKorisnika + "' , DatumPredaje = '" 
                    + this.datumPredaje.ToString() +"'";

            }
        }

        public string VrednostiAtributaZaUbacivanje
        {
            get
            {
                return "(" + this.evidencijaId + ", " + this.sifraKorisnika+
                    ", '" + this.datumPredaje.ToString() + ")";
            }
        }

        public IOpstiDomenskiObjekat NapuniObjekat(DataRow red)
        {
            Evidencija evidencija= new Evidencija();
            evidencija.evidencijaId = Convert.ToInt32(red["evidencijaId"]);
            evidencija.sifraKorisnika = Convert.ToInt32(red["sifraKorisnika"]);
            evidencija.datumPredaje = red["datumPredaje "].ToString();

            return evidencija;
        }
        #endregion
    }


Svaku sledecu klasu koju budem pravio trebam da pravim na isti nacin. Zato sam napravio ovaj IOpstiDomenskiObjekat. To je interfejs koji ima sve ove propertije i potpis ove zadnje metode. Tako mi je lakse da dodajem posle nove klase. Sada bih trebao prepraviti opstiManager da ne prima primarni kljuc i tabelu atributa, vec da prima ovaj objekat i da informacije koje mu trebaju vadi iz propertija ovog objekta. Nadam se da sam dobro ukapirao
mmix @ 05.07.2008. 12:48
Otprilike, samo sto ovo vise nije TDO vec BO pattern, sto je takodje ok.

Samo par primedbi:

Ako koristis C#3.0 ne mroas da pravis private polja za propertije, deklarisi samo kao
Code:

public int EvidencijaId { get; set; }


kompajler ce sam generisati implicitno polje za smestanje propertija.


IOpstiDomenskiObjekat ti malo kvari koncept DAO-a, tj ti se na nivou BO objekta bavis elementima koji su neophodni u DAO patternu, ubijas decoupling koji razdvaja BL i DL, sve te formacije parcijalnih SQL skripti koje imas rade OK na SQL serveru, a sta ako zamenis DAO tako da radi recimo sa XML fajlovima, sta onda, moras da promenis apsolutno sve BO objekte ?. Ono sto sam ja mislio je da u DAO imas posebnu klasu EvidencijaManager koji nasledjuje opstiManager a koja ce znati kako da iskoristi Evidencija klasu (koja bi tada bila TDO jer su preostali samo podaci) i u kojoj ces imati taj kod koji ovde imas u okviru implementacije IOpstiDomenskiObjekat. Pazi, ti mozes slobodno da imas posebnu biblioteku u kojoj su deklarisane TDO klase i koje koristi i BL i DL, BL da bi ih koristio, DL da bi ih ucitavao i snimao, to je sasvim ok, nije neophodno da postoji tipska separacija izmedju layera/patterna. Recimo treba ti evidencija broj 123, instanciras EvidencijaManager i pozoves UcitajEvidenciju(123) koji vraca instancu Evidencija. BL-a bas briga odakle je stigao taj objekat, dal iz SQLa, iz snimljenog XML fajla ili sa udaljenog web servisa, on barata sa TDO instancom.