Talk:Givela

XML retsensioon Double Trouble meeskonna poolt

Kõigepealt mainiks ära selle, et meeskonna Givela idee on väga huvitav ja kindlasti koguks populaarsust. On näha, et meeskond on teinud põhjaliku eeltöö selleks et projekti hea funktsionaalsus oleks tagatud. On loodud andembaasi tabel ja välja kirjutatud vaated, mis saavad projekti töös olema. XML on väga konkreetne ning sisaldab nõuetele vastavalt vähemalt neli dimensiooni. Iga elemendi juures on kasutatud on ka CDATAt, mis on samuti väga hea. Nõuetes oli ka kirjas, et kasutusel peavad olema attribuudid, mis on rohkem kui id, kuid neid ma kahjuks siin failis ei näe. Lisaks olemasolevale lisaksime enda poolt ka mingisugune algelise hinna, mille kasutaja saab sisestada ja ostja või siis nö annetaja otsustab ise, kas ta tahab seda annetussummat suurendada või mitte. XSD tundub korras olevat. XSLT faili on meeskonnal vaid üks, kuid kriteeriumiks oli vähemalt kaks transformatsiooni. Positiivne on, et kasutatud on rohkem tingimuslauseid kui oli nõutud ning et kasutatud on ka CSSi.

Retsenseeris meeskond DoubleTrouble.

Retsensioon veebiteenusele (Travo 2.0)

Givela serveri ülesseadmine on ülimalt lihtne, kui taustsüsteem on juba vastavalt konfigureeritud (töötav Microsoft SQL server, kompileerimiseks vajalikud .NET teegid olemas). Andmebaasi täitmisel näidisandmetega tekkis logisse küll üks välisvõtme konflikt, kuid see ei takistanud edukat demoks piisavate näidisandmete loomist.

Veebiteenuse süsteem on jaotatud nelja kihti: BLL, DAL, Domain ja Web-API. Käin läbi iga kihi eraldi.

Web-API kiht

Siin kihis peaksid asuma kontrollerid ja üldine API (veebiteenuse) konfiguratsioon. Koheselt torkab silma, et lisaks eeltoodule on siia pandud ka veebipõhine (AngularJS baasil) klientrakendus. Kiht on ka põimitud ASP.NET MVC tehnoloogiaga. Lühidalt tähendab see seda, et Web API kiht on segu kolmest tehnoloogiast: API teenusest, veebipõhisest klientrakendusest ja ASP.NET Web MVC-st (mille ainus reaalne ülesanne antud juhul on CSS ja JavaScript failide nimistute automaatne loomine (MVC enda tehnoloogiaid ei kasutata ja tegemist on puhtalt Angularil põhineva SPA-ga)). Siinkohal mainin, et samasse ämbrisse astusin eelmine aasta Meeskond: Travo projektiga.

Web API puhul leiavad reaalset kasutust neli kontrollerit: Bid-, Charity-, Product- ja AccountController. Edukalt on tööle saadud küpsistel põhinev autentimine ja sessioonihaldus (tokeni eluea pikkuses). Autoriseeritavad endpointid töötavad vastata annotatsiooniga. See on ilmselt kõige keerukam projekti osa ning on antud projektis edukalt funktsioneerima saadud.

Domain kiht

Siin asuvad mudelid on hästi kirjeldatud ning on tõrkeid takistavate annotatsioonidega.

BLL kiht

BLL kihis on jälgitud eeskujukalt Servicite loomise ja DTO-de tagastamise loogikat. DTO-d saadake läbi tavapärast Factory klassi. Kihi ülesehitus on eeskujulik; ainus norimiskoht oleks see, et Factoryd võiksilt vabalt olla static klassid.

DAL kiht

DAL kihis asetseb ootuspäraselt EntityFrameworkile vastav DbContext klass ja migratsioonid. Kasutatud on ka repository patternit. Repository pattern on realiseeritud korrektselt, luues igale repositoryle vastavat interfacei, mis võimaldab suuremat koodi eraldatust ning tõstab testitavust. Küll aga on näha, et üleminek pole veel lõpule viidud, kuna repositorydes asuvad vaid meetodid kõikide olemite tagastamiseks. See peegeldub ka vastavates service klassides.

Kokkuvõte

Kokkuvõtvalt öeldes on veebiteenuse struktuur hea ning eeskujulik. Tööle on saadud peamised funktsionaalsused: kasutajate haldus ja kasutajatele mõeldud sisu haldus. Selle kõige realiseerimiseks on kasutatud nelja kihti, kuhu on olnud plaan implementeerida service ja repository mustritega andmete lugemine ja jäädvustamine. Töö on veel poolik, nagu on kinnitanud ka projektijuht, kuid seni tehtud töö on suures mahus siiski äärmiselt pädev ning ollakse kindlasti õigel teel.

Kõike suuremaks murekohaks on Web API kiht, kuhu on kokku keedetud supp kolmest erinevast tehnoloogiast: ASP.NET Web API-st, ASP.NET MVC-st ja AngularJS klientrakendusest. Siin tuleks teha kerge puhastus, mille käigus oleks mõistlik eemaldada ASP.NET MVC täielikult ning tõsta AngularJS klientrakenduses eraldi projekti. Kui viia projektis pooleliolevad üleminekud (näiteks repositoride ja service klasside korrektne rakendus) lõpuni ning teha suurpuhastus Web API kihis, siis oleks veebiteenuse osa maksimumpunktide vääriline.

Retsenseeris Meeskond: Travo 2.0.