Talk:Meeskond "C terav"

XML osa arvustus

XML struktuur on korralikult tehtud, süntaksi vigu pole näha. Kuupäevad ja ajad on piisavalt täpselt ära kirjeldatud, et neid hiljem oleks kerge välja lugeda. Mis aga mina oleks natuke teistmoodi teinud, on näiteks aadresi väli, kus hetkel on väli nimega "linnVald" ja peale mida tuleb kohe "tanav", kui aga näiteks ma tahaks kirjeldada kohvikut, mis asub mingis maakohas x vallas, siis poleks enam kohta, kuhu kirjutada asula nime. Teine asi, mis natuke liiga jäik on, on lahtioleku ajad, näiteks kui tahaks märkida kohvikut, mis töötab iga päev esmaspäevast kuni pühapäevani, siis alati peaks panema nädalavahetuse päevad erandpäevade alla, vaatamata, et selle kohviku puhul võib näiteks laupäeval lahtiolemine täiesti tavaline olla.

Skeemifail on olemas, samuti ka XSLT. Kõik piisavalt hästi tehtud, XSLT tulemuses oleks võinud ainult kuupäev ja kellajad korralikumalt punktide või kooloniga eraldatud olla, et loetavus parem oleks.

Rauno Rüga

Rruga 20:55, 4 March 2011 (EET)

XML-i arvestus

XML on üpriski korralikult disainitud. Lahtiolekuaegade jaotus ei piina silmi. On võimalik puhtalt kirja panna lahtiolekuajad kohviku kohta, mille ajad mitme päeva puhul kattuvad, või siis läbi "aeg" elemendi kirjeldada erinevaid aegu erinevatel päevadel. Toitude jaotus menüüs on ka väga hästi tehtud, küll aga oleks ehk ise teinud toitudele ülemelemendid nagu "liik" või "kategooria" kuhu alla oleks võimalik toite lisada. Mis natuke kahtlust tekitas, oli toitude jaotamine koguse järgi ja seda hindade all. Koguse kirjeldus võiks ehk olla ise mingi elemendi sees (mitte elemendina). Praegu on vist eeldatud, et kõikidel toitudel/kaupadel on "tais", "poolik" jm ühised portsjonid.

Joosep Ilves

XML Arvustus

• Kuna ise teeme ka sarnast projekti võrdlen seda palju meie omaga. Teil on kohvikute kohta info väga hästi ja täpselt välja toodud. Võibolla isegi liiga täpselt kuna te ei või kunagi teada kes teil kliendiks registreerib, et kas ta üldse oskab enda koordinaate leida, see tähendaks teile rohkem tööd ja võib põhjustada kliendi frustratsiooni kui ka teile. Isiklikult mulle koordinaatide süsteem meeldib, saate nii teha ühe suure kaardi kuhu kõik kohvikud peale märkida.
• Toidud on toodud välja väga lihtsalt, aga samas tundub see lisade süsteem pisut mõttetu, restoranides on tavaliselt lisad veel eraldi ostetavad aga kohvikus tavaliselt ei osta kotletti ja kartulit eraldi. Kommentaarid on teil ka kohe xmliga ära kaetud, kuid me näiteks edastame vaid laikijad, üldjuhul kommenteeritakse siis kui toit oli halb mis võib rohkem halba teha kohvikule kui head, aga jah, maitse asi. Portsude osa lahendasime sama moodi ja see meeldib.
• Üldiselt on XMLil korralik laotus, aga liigne keskendumine kohvikule endale kui menüüle, mis minu arvates on peamine.

• Jaan Kruusma D22

XML Arvustus

Kohe hakkab silma fakt et teie süsteem ei toeta mitut kohvikut, tunnen et see on suur miinus kuna süsteemi praktiline väärtus on seetõttu väga madal - ma saan aru, et te teete seda ühele kliendile, aga mis siis kui see üks klient tahab teie süsteemi mitmes kohvikus hakata kasutama tulevikus? Teiseks tundub väga overkill see ajatempli lahtikiskumine juppideks, lihtsam oleks kasutada mingit UNIX timestampi moodi asja ja siis kasutajaliideses see loetavaks ajaks koverteerida. Samuti on ülisuur miinus ajatsooni puudumine - sisuliselt ei saa teie programmi kasutada korraga ühe kliendi poolt mitmes riigis. Kolmandaks kriibib silma see "Eurohind", kas te mõtete teha nii et iga klient peab kasutajaliidesse kirjutama oma rahaühiku ja siis konverteeritakse on-the-fly eurodest või peab hakkama XMLi iga välisriigi jaoks eraldi täiustama?

Muu on normaalne ja eriti meeldib teie kolmekihiline süsteem.

Tanel Liiv D22

XML Arvustus

Mis meeldis ning mis ei karjunud oli lahtioleku aegade jaotus - oli lihtsalt ja arusaadavalt tehtud. Mis silma hakkas oli see, et seal on välja toodud küll väikesed ja suured portsud, kuid see kas ports saadaval on, käib siinkohal toidu kohta, see tähendab seda, et kui näiteks suur ports otsas on, siis ei tähenda see automaatselt seda, et poolikut portsu pole ka võimalik saada. Kui näitena võetud meie ITK kohvik, siis seal ennegi olnud näiteks ainult pool portsu alles. Samas oleks võinud kommentaaride alla lisada ka kuupäeva, millal seda antud toitu kommenteeritud on, et oleks võimalik näiteks viis kõige uuemat kommentaari kuvada. Üldjuhul võib rahule jääda, kõik tähtis oli ära kirjeldatud, vigu ei leidnud ka skeemifailist ega XSLT'st.

Kaspar Kallasmaa D21

Teenuskihi Arvustus

Antud projekti teenuskihi juures jääb kohe silma, et andmemudel oleks justkui andmebaas ( wiki veebiteenuse alampunkti põhjal tekib selline mulje ). Lisaks pole pakutavas zip failis andmebaasi, mis toetab mainitud väidet. See aga on minuarust küll väga vale lähenemine, kuna teil on tehtud dbml andmemudeli fail, mis aga pole mõeldud üldsegi selleks, et selle põhjal andmebaasi genereerida. Võibolla kuidagi see õnnestuks, aga sellist funktsionaalsust .net ametlikult küll ei toeta.

Teine asi, mis oleks võinud teistmoodi olla, on valitud projekti tüüp. Kui juba WCF valisite teenuskihi jaoks, oleks võinud selle jaoks eraldi WCF projekti teha, hetkel on seal palju üleliigset asp.net träni kaasas, mis ei puutu üldse teenuskihti.

Liigudes edasi koodini ja meetoditeni, märkasin et tagastate teenuskihis alati klasse, isegi siis kui toimub millegi sisestus "teie andmebaasi" ja tagasi oleks vaja saada vaid booleani, et kas asi õnnestus või mitte. Suure teenuskihi kasutusel lisaks see kindlasti suurt koormust, kui lihtsa booli tagastamise asemel on vastuseks mingi suuremat sorti klass. Silma jäi ka järgnev koht koodis:

KasutajaKirjeClass KKC = new KasutajaKirjeClass();
        if ( KKC.kontrolliKohvikuKasutaja(kohvikID, kasutajaID) == true)
        {
            try
            {
                kont.ExecuteCommand("insert into Menyy(fkKohvik_id,alates,kuni) values('" + kohvikID + "','" + alates.ToString("MM.dd.yyyy") + "','" + kuni.ToString("MM.dd.yyyy") + "');");

                return true;
            }
            catch
            {
                return false;
            }
        }
        else {
            return false;
        }

Kontrolli sisu on siin:

 public bool kontrolliKohvikuKasutaja(int kohvikID, int kasutajaID)
    {
        var kasutajaOlemas = kont.KohvikuKasutajas.Where(x=>x.fkKohvik_ID==kohvikID && x.fkKasutaja_ID == kasutajaID).SingleOrDefault();

        if (kasutajaOlemas == null)
        {
            return true;
        }
        else
        {
            return false;
        }
    }

Hetkel toimib süsteem nii, et kui antud kohviku id ja kasutaja id-ga kasutaja on andmebaasis, siis kasutajaOlemas muutuja saab selle objekti endale (mis pole kaugeltki turvaline autentimine) ja järgneva tingimuse põhjal tagastatakse false, seega väljakutsuvas meetodis ei täideta sql käsku. Käsk aga täidetakse sellisel juhul, kui andmebaasist ei leitud sellist kasutajat, kas mitte see süsteem vastupidi ei peaks töötama !? Sama asi oli veel mitmes kohas. Oleksite võinud ka valida ühe stiili, kas linq kasutamise või siis ainult sql käsud, hetkel läbisegi nii ühte kui teist kasutatud.

Head oli ka, see asi mis teil tehtud, oli tähtajaks valmis.

Rauno Rüga Rruga