Talk:Meeskond:Valar Morghulis

From ICO wiki
Revision as of 16:08, 8 June 2015 by Sniinepu (talk | contribs) (Created page with "=Teenuse ja kliendi retsensioon meeskonnalt Dot muzei= ==Teenus== '''Domeeni mudelid:''' Domeeni mudeli põhjal loodud POCO’d järgivad andmemudelis defineeritud seoseid. Ole…")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Teenuse ja kliendi retsensioon meeskonnalt Dot muzei

Teenus

Domeeni mudelid:

Domeeni mudeli põhjal loodud POCO’d järgivad andmemudelis defineeritud seoseid. Olemid on varustatud Data Annotatsioonidega, mis defineerivad tabeli väljade omadusi. Lisaks sellele on defineeritud ka eesti keelsed veateated. Sõned tabeliväljades on piiratud. Lisaks sellele on domeenimudelisse lisatud Identity projekti olemid ning Identity projekti kasutaja on seotud domeeni mudeliga.

DAL:

Andmekäitlus kiht on loodud kasutades kõiki nõutud disaini mustreid nagu seda on UOW, repositooriumid, liidesed, vabriku muster ja code-first andmebaas. Enamus domeenimudelid on loodud läbi standard repositooriumite. Erandiks on siinkohal AppUserRepository, mille jaoks on loodud eraldi repositoorium. Standard repositooriumi liidesele on lisatud teenuse spetsiifilisi meetodeid andmetöötluseks. Igale repole on loodud ka vastav liides. Samuti on andmekäitlus kihis ka Identity projektiga seotud liidesed ja repositooriumid. Andmekäitlus kiht vastab igati nõutud kriteeriumitele ning midagi anomaalset seal ei esine. Järgitud on häid tavasid ning on näha, et projekti autor on teinud tööd põhjalikusega ning mõistab enda poolt loodud projekti arhitektuuri.

Äriloogika kiht:

Äriloogika kiht on varustatud DTO-dega, mis võimaldavad edastada mudeli kohta soovitud andmeid. DTO-de loomiseks on olemas vabrikud, mis läbi vabriku mustri võimaldavad luua uusi DTO objekte vastavalt olemitele, mida DTO kirjeldab. Äriloogika kiht on varustatud ka meetoditega, mis tegelevad andmepäringutega. Hetke seisu järgi tundub nagu osa meetodeid on jäänud implementeerimata või ei osutunud need rakenduse jaoks vajalikuks. Äriloogika kiht on järjekordselt korrektselt tehtud ning pretentsioone selles osas ei ole. Teenuse autor on läbimõelnud oma lahenduse ning järginud häid tavasid koodi kirjutamisel.

WebApi:

Veebi teenus kasutab ära SSL-i ning töötab üle HTTPS-i, mis on väga oluline tagamaks, et teenus oleks turvaline. Lisaks Identity projektist kaasa tulnud kontrolleritele ja home kontrollerile on teenuses olemas veel 2 autori enda loodud kontrollerit. Kontrollerid töötavad üle Unit of Worki, kahjuks pole Dispose meetodid välja kommenteeritud. Samuti pole ka kontrollerite enda meetodid varustatud dokumentatsiooni stiilis kommentaaridega, mis võimaldaksid teistel arendajatel paremini teenuse sisust aru saada. Küll on aga meetodi nimed iseennast kirjeldavad. Lisaks CRUD operatsioonidele on ka teenuse spetsiifilised meetodid. Teenuse lehe kasutajaliides ja selle laotus on muutmata ja vastab algupärasele avakuvale. Teenuses on kasutatud sõltuvuse süstimist ning see on realiseeritud läbi Ninjecti. Teenus ise vastab üldjoontes headele tavadele ja kasutab nõutud võtteid.


Klient

Admin paneel:

Admin paneeli valikuks on kasutatud modernse välimusega admin paneeli template’i, mis annab rakendusele professionaalset välimust. Lisaks sellele on template varustatud ka erinevate widgetitega, mis lisavad nii võimalusi template’i välimuse muutmiseks kui ka annavad teada, mis kell on. Admin rakendus on ühendatud Identity projektiga. Samuti kasutab rakendus ka HTTPS-i, mis on ainumõeldav turvaline lahendus rakenduse jaoks, mis võimaldab pea kõike muuta. Kõikide domeenimudelite jaoks on oma kontrollerid, ka Identity projektist tulnud olemite jaoks. Defineeritud on baas kontroller, kuid seda ei ole kasutusele võetud. Samuti suhtlevad paljud kontrollerid andmebaasiga läbi Entity raamistiku. Ainult teenuse enda domeeni mudelid kasutavad Unit of Worki. Vaatemudeleid ei ole peamiste domeenimudelite kohta loodud ning paljudesse kohtadesse on sisse jäänud viewbagid. Rakendus kasutab ka sõltuvuse süstimist. Tundub, et administratsiooni paneeli prioriteet on olnud projekti juures kõige madala väärtusega, kuid arvestades, et projekt on tehtud üksi ja võrdlemisi põhjalikult, siis ei selle tõttu autorit väga kritiseerida. Rakendus ise täidab oma funktsionaalsust ning võimaldab kõiki olemeid modifitseerida või luua.

Klient:

Klient suhtleb teenusega üle HTTP, mis oli kliendi puhul vajalik nõue. Suhtlus teenusega on defineeritud läbi teenuste klasside, mis kõik pärinevad baasteenuse klassist. Tundub, et mingil hetkel on autor soovinud klienti luua kasutades Angular.js-i, kuid tõenäoliselt leidis sellise lahenduse alustamiseks liiga raske olevat. Rakendus suhtleb teenusega üle HTTPS-i, mis on järjekordselt turvalisuse tagamiseks väga oluline nüanss. Ainuke kontroller projektis on Home kontroller, mis tegeleb kõigi vaadete kuvamisega. See on veidi kummaline, kuid arvestades kliendi poolset lihtsat funktsionaalsust, mis on keskendunud väheste operatsioonide tegemisele, siis see annab vihjeid, misk autor on sellise valiku teinud. Isiklikult oleks ma siiski loonud olemite jaoks eraldi kontrollerid ja läbi kontrollerite operatsioonide jaoks välja kutsunud rakenduse teenustes defineeritud meetodeid. Mis puudutab audentimist ja autoriseerimist, siis sellega on autor edukalt hakkama saanud. Puudu on veel viimased lihvid, sest kohati on näha, et palju funktsionaalsust on hetkel kokku liigendatud nii, et rakendus toimiks. Soovitaks olemite jaoks luua eraldi kontrollerid ning kui kontrolleri meetod ei tagasta põhimõtteliselt midagi, siis soovitaks kaaluda selle eemaldamist. Iga kontrolleri jaoks võiksid olla oma vaated ning kui vaja, siis ka vaatemudelid. Vaated vajaksid kordategemist. Siiski arvestades, et kogu projekt on ühe inimese poolt loodud, siis töö mahtu arvestades piirdun pretentsioonidega.


Retsenseeris meeskond Dot muzei