Talk:DevHelpVR: Difference between revisions
No edit summary |
|||
| (2 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
==Sissejuhatus== | ==Sissejuhatus== | ||
Sorry, kuna meil viide pealehelt retsensioonile oli sama, siis kukkusin kohe kirjutama. Võtan oma osa ära, jätan teie oma alles. | |||
Mihkel (Talutooted). | |||
==Tehnoloogilise osa arvustus== | |||
=== '''Veebiteenus''' === | |||
== | |||
''' | |||
= | |||
=== Domeenimudelid === | ==== Domeenimudelid ==== | ||
Veebiteenuse domeenimudelid on kirjeldatud üsna põhjalikult ja meeldib, et mõistlikes kohtades on kasutatud annotatsioone – näiteks piiratud stringi pikkused ja lisatud required väljad kuhu vaja. Mudeleid on kokku kümne ringis, mis viitab sellele, et projekt tundub nõudeid arvestades paraja suurusega. Lisaks on leidub eraldi kaust, kus on realiseeritud | Veebiteenuse domeenimudelid on kirjeldatud üsna põhjalikult ja meeldib, et mõistlikes kohtades on kasutatud annotatsioone – näiteks piiratud stringi pikkused ja lisatud ''required'' väljad kuhu vaja. Mudeleid, nagu eelpool mainitud, on kokku kümne ringis, mis viitab sellele, et projekt tundub nõudeid arvestades paraja suurusega. Lisaks on leidub eraldi kaust, kus on realiseeritud ''Enum''’itena erinevad fikseeritud skaalaga väljad. Veel torkab silma, et kasutatakse ''Lazy Loading''’ut, mis antud rakenduse suuruse juures pole võib-olla kõige vajalikum, sest ei anna üldjuhul efekti Uow ja Repository mustrite kasutuse tõttu. Samuti võib see tulevikus raskendada rakenduse üle viimist ASP.NET Core’i peale, mis seda ei toeta. Natukene häirivad mõned mitu-mitmele seoste tulemusel tekkivate olemite nimetused – näiteks User_DevTeam või User_Project. Võib-olla oleks silmale veidi ilusam neid ilma alakriipsuta kirjutada, kuid see on paljuski isiklik eelistus. Kokkuvõtvalt aga peab mainima, et mudelid tunduvad hästi läbi mõeldud ning siinkohal on etteheiteid teha raske. | ||
=== Andmebaas ja repositooriumid === | ==== Andmebaas ja repositooriumid ==== | ||
Arhitektuuri osas on kasutatud Repository | Arhitektuuri osas on kasutatud Repository mustrit ''db-context'''i vastu, samuti Unit of Work mustrit, mis koondab enda alla repositooriumid. Kiita saab seda, et Helpers kataloogis on DbInitializer, mis teeb konkreetset koodi mittetundvale inimesele rakenduse järgiproovimise lihtsaks (ei pea ise dummy data’t genereerima, vaid saab kohemaid sisusse süveneda). Repositooriumite osas torkab silma, et need on enamjaolt tühjad (peale UserRepository), kuid UOW-s registreeritakse need custom repositooriumitena. Loomulikult võib need tuleviku arendusi silmas pidades valmis ära teha, kuid siis pole suurt mõtet neid veel eraldi Dictionary-sse registreerida vaid kasutada UOW-s standardsetena. Iga repositooriumi vastu on kirjutatud eraldi Interface, nii repositooriumid, kui Interface’id kasutavad baasmudelit (vastavalt EFRepository ja IRepository), millest nad pärinevad, mis näitab ka, et tuntakse hästi ka objekt-orienteerituse põhitõdesid. | ||
=== Äriloogika === | ==== Äriloogika ==== | ||
Kontrollerid suhtlevad antud juhul service | Kontrollerid suhtlevad antud juhul teenuse kihiga (''service layer'') ja kasutatakse DTO-sid koos Factory mustriga. DTO-d tunduvad kõik domeenimudelitega identsed ja on seega ilmselt valmis tehtud just tulevikku silmas pidades. Kontrollerites on realiseeritud enamjaolt ''CRUD'' meetodid, mis kasutavad DTO-sid, ja väga palju spetsiifilisi lahendusi realiseeritud ei ole. Kontrolleritele võiks vaid nii palju ette heita, et ei kasutata asünkroonset lähenemist, mis teeks rakenduse tulevikus veelgi skaleeritavamaks, kuid mis põhiline, lubaks rakendust paindlikumalt kasutada. Samas, nii repositooriumid kui kontrollerid on õiges kohas ja õigesti üles ehitatud ning kõik tundub ilusasti töötavat. Ainus, mida saaks ära märkida, on osade kontrollerite puhul vea korral 404 veateate mitte tagastamine. Kasutajate haldus kasutab ''Entity Framework''-i enda ''ApplicationUser''’it, seega aine baas-repositooriumis välja pakutud ''Custom Identity'' lahendust ei ole siinkohal realiseeritud (mis ei olnud ka ise-enesest eraldi nõue). | ||
=== Kokkuvõte === | ==== Kokkuvõte ==== | ||
Teenuse juures torkab silma, et meeskond tunneb hästi arhitektuurilisi võtteid, kuidas veebirakendusi loogiliselt üles ehitada. Kuigi rakendus praeguses mahus kõiki neid kihte veel ei vaja, annab see võimaluse tulevikus teenust lihtsasti skaleerida, kuna kihid on juba algusest saati ilusasti paigas. Sellest annab ka tunnistust see, et näiteks DTO-de ja domeenimudelite väljad hetkel kattuvad, kuid tulevikus on lihtsasti võimalik teha andmebaasis muudatusi ja täiendusi ilma neid kliendile kohe välja näitamata. Kood on enam-vähem korralikult kommenteeritud, kuid mõndades kohtades jäi silma pikk doctype kommentaaride rida, mis oli kirjutatud Eesti keeles. Kuna Visual Studio genereerib uut rakendust tehes ka palju ingliskeelseid kommentaare, võiks kaaluda ühtse stiili kasutamist ning vältida eestikeelset teksti koodi vahel. Kokkuvõtvalt tuleb meeskonda kiita tubli töö eest. Teenus on väga korralikult üles ehitatud ning järgib paljusid mustreid, mis on täna tõsiseltvõetavate rakenduste tunnuseks. Kuigi sellise mahuga rakenduse võiks kirjutada vabalt ka ilma UOW vahekihita, näitab selle kasutamine teatavat vilumust ning teeb teenuse juures tulevikus muudatuste tegemise lihtsamaks. Arvestades, et meeskonnas oli vaid kaks liiget, väärib see projekt | Teenuse juures torkab silma, et meeskond tunneb hästi arhitektuurilisi võtteid, kuidas veebirakendusi loogiliselt üles ehitada. Kuigi rakendus praeguses mahus kõiki neid kihte veel ei vaja, annab see võimaluse tulevikus teenust lihtsasti skaleerida, kuna kihid on juba algusest saati ilusasti paigas. Sellest annab ka tunnistust see, et näiteks DTO-de ja domeenimudelite väljad hetkel kattuvad, kuid tulevikus on lihtsasti võimalik teha andmebaasis muudatusi ja täiendusi ilma neid kliendile kohe välja näitamata. Kood on enam-vähem korralikult kommenteeritud, kuid mõndades kohtades jäi silma pikk doctype kommentaaride rida, mis oli kirjutatud Eesti keeles. Kuna Visual Studio genereerib uut rakendust tehes ka palju ingliskeelseid kommentaare, võiks kaaluda ühtse stiili kasutamist ning vältida eestikeelset teksti koodi vahel. Kokkuvõtvalt tuleb meeskonda kiita tubli töö eest. Teenus on väga korralikult üles ehitatud ning järgib paljusid mustreid, mis on täna tõsiseltvõetavate rakenduste tunnuseks. Kuigi sellise mahuga rakenduse võiks kirjutada vabalt ka ilma UOW vahekihita, näitab selle kasutamine teatavat vilumust ning teeb teenuse juures tulevikus muudatuste tegemise lihtsamaks. Arvestades, et meeskonnas oli vaid kaks liiget, väärib see projekt kindlasti maksimumpunkte! | ||
== Klientrakendus == | === Klientrakendus === | ||
=== Arhitektuur === | ==== Arhitektuur ==== | ||
Klientrakendus on realiseeritud | Klientrakendus on realiseeritud ''WPF application''’ina ning asub samas solution’is. Klientrakendus kasutab samu domeenimudeleid ning samuti on olemas Enum’ite kaust fikseeritud skaalaga väljade jaoks. Nii nagu teenuse osas, häirivad veidi silma alakriipsuga deklareeritud väljad (nt. User_UserStoryStart), kuid see on jällegi puhtalt stiili küsimus. Klientrakenduse domeenimudelid suhtlevad veebiteenuse API-ga tokenite abil, mis initsialiseeritakse konstruktoris. Samuti on olemas vaatemudelid, mis pärinevad baas vaatemudelist BaseVM, mis on põhimõtteliselt ''event handler''. Vaated näevad välja nagu nad out of the box on - eristuvat disaini ei ole siinkohal märgata. Samas on see arusaadav, kuna projekti maht oli niigi suur ja põhifookus lasus funktsionaalsuse realiseerimisel. Eraldi on olemas teenuse kiht (''service layer''), mille ülesandeks on andmete edastamine API vastu. Iga domeenimudeli jaoks on eraldi teenusekihi funktsionaalsus, mis pärineb baas ''service''’ist. Mõne vaatemudeli puhul jäi silma, et see kasutab väga palju teenusekihi klasse (näiteks DevTeamVM kasutab viite service’it). Siinkohal oleks võinud kaaluda teha lisaabstraktsioon, mis koondaks enda alla service-id. Idee poolest võiks see olla nagu UOW (Unit of Work), mida saaks süstida vaatemudelitesse, et need võiksid kasutada kõiki vajaminevaid teenusekihi klasse. Teisalt ei ole projekti maht niivõrd suur ja see võib vabalt jääda ka tulevikuks. | ||
=== Funktsionaalsus === | ==== Funktsionaalsus ==== | ||
Rakendust avades kuvatakse kõigepealt sisselogimise aken, kust on konto puudumisel võimalik kohe ka uus kasutaja registreerida. Peale registreerimist võiks kuvada lisaakna, millega kinnitada kasutajale, et registreerimine tõepoolest õnnestus. Praegu suunatakse lihtsalt tagasi sisselogimise aknasse. Peale sisselogimist avaneb “põhiaken”, kus saab kasutada juba põhifunktsionaalsust - siduda kasutajat projektide ja arendusmeeskondadega, projektidele lisada iteratsiooni ning iteratsioonidele kasutajalugusid. Nii projekte, kasutajalugusid kui iteratsioone saab sealjuures eraldiseisvalt kustutada ning ülemkategooria kustutamisel kaovad ka alamüksused (cascade delete). Siin tuleb selgelt välja, et domeenimudelid on läbimõeldud ning lisatud vajalikud väljad. Samas ei ole “surnud” välju, mida kuskil ei kasutata ja mis niisama objekti küljes on. Lisaks on võimalik vaadata statistikat ning muuhulgas jälgitakse ka kasutajate sisselogimiste arvu (teatavasti oli sisselogimiste arvu piiramine ka üks projekti nõuetest). | Rakendust avades kuvatakse kõigepealt sisselogimise aken, kust on konto puudumisel võimalik kohe ka uus kasutaja registreerida. Peale registreerimist võiks kuvada lisaakna, millega kinnitada kasutajale, et registreerimine tõepoolest õnnestus. Praegu suunatakse lihtsalt tagasi sisselogimise aknasse. Peale sisselogimist avaneb “põhiaken”, kus saab kasutada juba põhifunktsionaalsust - siduda kasutajat projektide ja arendusmeeskondadega, projektidele lisada iteratsiooni ning iteratsioonidele kasutajalugusid. Nii projekte, kasutajalugusid kui iteratsioone saab sealjuures eraldiseisvalt kustutada ning ülemkategooria kustutamisel kaovad ka alamüksused (cascade delete). Siin tuleb selgelt välja, et domeenimudelid on läbimõeldud ning lisatud vajalikud väljad. Samas ei ole “surnud” välju, mida kuskil ei kasutata ja mis niisama objekti küljes on. Lisaks on võimalik vaadata statistikat ning muuhulgas jälgitakse ka kasutajate sisselogimiste arvu (teatavasti oli sisselogimiste arvu piiramine ka üks projekti nõuetest). | ||
=== Kokkuvõte === | ==== Kokkuvõte ==== | ||
Klientrakendus on korralikult kirjutatud ning arvestades | Klientrakendus on korralikult kirjutatud ning arvestades kogu projektimahtu, ei ole sellele palju ette heita. Disaini osas oleks võinud mõelda klienti realiseerida siiski veebirakendusena, kasutades näiteks ''AngularJS''-i veebiraamistikuna ja näiteks ''Bootstrap'' raamistiku elemente. Samas võib omast kogemusest öelda, et kindlasti ei ole see ajasäästlikum tee, kui tehnoloogiad hästi ei valda (arvestades, et aine raames ''Angular'' raamistikust väga midagi rääkida ei jõutud). Selle tulemusena oleks saanud disaini ka veidi parema teha, kuid kõige tähtsam on siiski funktsionaalsuse realiseerimine, mis õnnestus väga hästi ja mille eest tuleb meeskonda kiita. Ükski lahendus ei tundu poolik, ning kõik on suures plaanis läbi mõeldud. Siit jääb kuvama ka tõsiasi, et see projekt on tegelikult edasiarendus C# aines kirjutatud projektile ning võib arvata, et seetõttu oli ka andmebaasi struktuuri ülesehitamine selle võrra lihtsam. Mõte ise on samuti hea. Kui meeskonnal tekiks tahtmine asja päriselt realiseerida, oleks nüüd lihtne võtta teenus ning teha sellele lisaks otsa korralik veebirakendus, mis näeb ilus välja. | ||
Latest revision as of 08:42, 15 June 2017
Retsensioon projektile DevHelpVR
Sissejuhatus
Sorry, kuna meil viide pealehelt retsensioonile oli sama, siis kukkusin kohe kirjutama. Võtan oma osa ära, jätan teie oma alles. Mihkel (Talutooted).
Tehnoloogilise osa arvustus
Veebiteenus
Domeenimudelid
Veebiteenuse domeenimudelid on kirjeldatud üsna põhjalikult ja meeldib, et mõistlikes kohtades on kasutatud annotatsioone – näiteks piiratud stringi pikkused ja lisatud required väljad kuhu vaja. Mudeleid, nagu eelpool mainitud, on kokku kümne ringis, mis viitab sellele, et projekt tundub nõudeid arvestades paraja suurusega. Lisaks on leidub eraldi kaust, kus on realiseeritud Enum’itena erinevad fikseeritud skaalaga väljad. Veel torkab silma, et kasutatakse Lazy Loading’ut, mis antud rakenduse suuruse juures pole võib-olla kõige vajalikum, sest ei anna üldjuhul efekti Uow ja Repository mustrite kasutuse tõttu. Samuti võib see tulevikus raskendada rakenduse üle viimist ASP.NET Core’i peale, mis seda ei toeta. Natukene häirivad mõned mitu-mitmele seoste tulemusel tekkivate olemite nimetused – näiteks User_DevTeam või User_Project. Võib-olla oleks silmale veidi ilusam neid ilma alakriipsuta kirjutada, kuid see on paljuski isiklik eelistus. Kokkuvõtvalt aga peab mainima, et mudelid tunduvad hästi läbi mõeldud ning siinkohal on etteheiteid teha raske.
Andmebaas ja repositooriumid
Arhitektuuri osas on kasutatud Repository mustrit db-context'i vastu, samuti Unit of Work mustrit, mis koondab enda alla repositooriumid. Kiita saab seda, et Helpers kataloogis on DbInitializer, mis teeb konkreetset koodi mittetundvale inimesele rakenduse järgiproovimise lihtsaks (ei pea ise dummy data’t genereerima, vaid saab kohemaid sisusse süveneda). Repositooriumite osas torkab silma, et need on enamjaolt tühjad (peale UserRepository), kuid UOW-s registreeritakse need custom repositooriumitena. Loomulikult võib need tuleviku arendusi silmas pidades valmis ära teha, kuid siis pole suurt mõtet neid veel eraldi Dictionary-sse registreerida vaid kasutada UOW-s standardsetena. Iga repositooriumi vastu on kirjutatud eraldi Interface, nii repositooriumid, kui Interface’id kasutavad baasmudelit (vastavalt EFRepository ja IRepository), millest nad pärinevad, mis näitab ka, et tuntakse hästi ka objekt-orienteerituse põhitõdesid.
Äriloogika
Kontrollerid suhtlevad antud juhul teenuse kihiga (service layer) ja kasutatakse DTO-sid koos Factory mustriga. DTO-d tunduvad kõik domeenimudelitega identsed ja on seega ilmselt valmis tehtud just tulevikku silmas pidades. Kontrollerites on realiseeritud enamjaolt CRUD meetodid, mis kasutavad DTO-sid, ja väga palju spetsiifilisi lahendusi realiseeritud ei ole. Kontrolleritele võiks vaid nii palju ette heita, et ei kasutata asünkroonset lähenemist, mis teeks rakenduse tulevikus veelgi skaleeritavamaks, kuid mis põhiline, lubaks rakendust paindlikumalt kasutada. Samas, nii repositooriumid kui kontrollerid on õiges kohas ja õigesti üles ehitatud ning kõik tundub ilusasti töötavat. Ainus, mida saaks ära märkida, on osade kontrollerite puhul vea korral 404 veateate mitte tagastamine. Kasutajate haldus kasutab Entity Framework-i enda ApplicationUser’it, seega aine baas-repositooriumis välja pakutud Custom Identity lahendust ei ole siinkohal realiseeritud (mis ei olnud ka ise-enesest eraldi nõue).
Kokkuvõte
Teenuse juures torkab silma, et meeskond tunneb hästi arhitektuurilisi võtteid, kuidas veebirakendusi loogiliselt üles ehitada. Kuigi rakendus praeguses mahus kõiki neid kihte veel ei vaja, annab see võimaluse tulevikus teenust lihtsasti skaleerida, kuna kihid on juba algusest saati ilusasti paigas. Sellest annab ka tunnistust see, et näiteks DTO-de ja domeenimudelite väljad hetkel kattuvad, kuid tulevikus on lihtsasti võimalik teha andmebaasis muudatusi ja täiendusi ilma neid kliendile kohe välja näitamata. Kood on enam-vähem korralikult kommenteeritud, kuid mõndades kohtades jäi silma pikk doctype kommentaaride rida, mis oli kirjutatud Eesti keeles. Kuna Visual Studio genereerib uut rakendust tehes ka palju ingliskeelseid kommentaare, võiks kaaluda ühtse stiili kasutamist ning vältida eestikeelset teksti koodi vahel. Kokkuvõtvalt tuleb meeskonda kiita tubli töö eest. Teenus on väga korralikult üles ehitatud ning järgib paljusid mustreid, mis on täna tõsiseltvõetavate rakenduste tunnuseks. Kuigi sellise mahuga rakenduse võiks kirjutada vabalt ka ilma UOW vahekihita, näitab selle kasutamine teatavat vilumust ning teeb teenuse juures tulevikus muudatuste tegemise lihtsamaks. Arvestades, et meeskonnas oli vaid kaks liiget, väärib see projekt kindlasti maksimumpunkte!
Klientrakendus
Arhitektuur
Klientrakendus on realiseeritud WPF application’ina ning asub samas solution’is. Klientrakendus kasutab samu domeenimudeleid ning samuti on olemas Enum’ite kaust fikseeritud skaalaga väljade jaoks. Nii nagu teenuse osas, häirivad veidi silma alakriipsuga deklareeritud väljad (nt. User_UserStoryStart), kuid see on jällegi puhtalt stiili küsimus. Klientrakenduse domeenimudelid suhtlevad veebiteenuse API-ga tokenite abil, mis initsialiseeritakse konstruktoris. Samuti on olemas vaatemudelid, mis pärinevad baas vaatemudelist BaseVM, mis on põhimõtteliselt event handler. Vaated näevad välja nagu nad out of the box on - eristuvat disaini ei ole siinkohal märgata. Samas on see arusaadav, kuna projekti maht oli niigi suur ja põhifookus lasus funktsionaalsuse realiseerimisel. Eraldi on olemas teenuse kiht (service layer), mille ülesandeks on andmete edastamine API vastu. Iga domeenimudeli jaoks on eraldi teenusekihi funktsionaalsus, mis pärineb baas service’ist. Mõne vaatemudeli puhul jäi silma, et see kasutab väga palju teenusekihi klasse (näiteks DevTeamVM kasutab viite service’it). Siinkohal oleks võinud kaaluda teha lisaabstraktsioon, mis koondaks enda alla service-id. Idee poolest võiks see olla nagu UOW (Unit of Work), mida saaks süstida vaatemudelitesse, et need võiksid kasutada kõiki vajaminevaid teenusekihi klasse. Teisalt ei ole projekti maht niivõrd suur ja see võib vabalt jääda ka tulevikuks.
Funktsionaalsus
Rakendust avades kuvatakse kõigepealt sisselogimise aken, kust on konto puudumisel võimalik kohe ka uus kasutaja registreerida. Peale registreerimist võiks kuvada lisaakna, millega kinnitada kasutajale, et registreerimine tõepoolest õnnestus. Praegu suunatakse lihtsalt tagasi sisselogimise aknasse. Peale sisselogimist avaneb “põhiaken”, kus saab kasutada juba põhifunktsionaalsust - siduda kasutajat projektide ja arendusmeeskondadega, projektidele lisada iteratsiooni ning iteratsioonidele kasutajalugusid. Nii projekte, kasutajalugusid kui iteratsioone saab sealjuures eraldiseisvalt kustutada ning ülemkategooria kustutamisel kaovad ka alamüksused (cascade delete). Siin tuleb selgelt välja, et domeenimudelid on läbimõeldud ning lisatud vajalikud väljad. Samas ei ole “surnud” välju, mida kuskil ei kasutata ja mis niisama objekti küljes on. Lisaks on võimalik vaadata statistikat ning muuhulgas jälgitakse ka kasutajate sisselogimiste arvu (teatavasti oli sisselogimiste arvu piiramine ka üks projekti nõuetest).
Kokkuvõte
Klientrakendus on korralikult kirjutatud ning arvestades kogu projektimahtu, ei ole sellele palju ette heita. Disaini osas oleks võinud mõelda klienti realiseerida siiski veebirakendusena, kasutades näiteks AngularJS-i veebiraamistikuna ja näiteks Bootstrap raamistiku elemente. Samas võib omast kogemusest öelda, et kindlasti ei ole see ajasäästlikum tee, kui tehnoloogiad hästi ei valda (arvestades, et aine raames Angular raamistikust väga midagi rääkida ei jõutud). Selle tulemusena oleks saanud disaini ka veidi parema teha, kuid kõige tähtsam on siiski funktsionaalsuse realiseerimine, mis õnnestus väga hästi ja mille eest tuleb meeskonda kiita. Ükski lahendus ei tundu poolik, ning kõik on suures plaanis läbi mõeldud. Siit jääb kuvama ka tõsiasi, et see projekt on tegelikult edasiarendus C# aines kirjutatud projektile ning võib arvata, et seetõttu oli ka andmebaasi struktuuri ülesehitamine selle võrra lihtsam. Mõte ise on samuti hea. Kui meeskonnal tekiks tahtmine asja päriselt realiseerida, oleks nüüd lihtne võtta teenus ning teha sellele lisaks otsa korralik veebirakendus, mis näeb ilus välja.
