Talk:Kassarakendus: Difference between revisions

From ICO wiki
Jump to navigationJump to search
Hlaasmag (talk | contribs)
Created page with "Teeb meeskond Bomory. IN PROGRESS"
 
Ttammeju (talk | contribs)
No edit summary
 
Line 1: Line 1:
Teeb meeskond Bomory. IN PROGRESS
== Rakenduse kasutamise esmamulje ==
 
Tehtud on põhjalik kasutajajuhend rakenduse kasutamiseks. Kuigi peab tõdema, et kogu see protsess on kasutaja jaoks üsna ebamugavaks tehtud. Et programmi käivitada tuleb teha manuaalselt andmebaasis endale kasutaja, koos kõigi vajalike (NOT NULL) väljadega. See jätab kasutajale palju eksimisruumi (nt kuupäevade formaat jms) ja on lihtsalt ajakulukas. Programmiga oleks võinud kaasas olla .sql script mis vastava kasutaja programmi käivitades ise loob. Järgmises punktis on loodud kasutajale rakenduse .exe shortcut, mis peaks rakenduse mugavalt käivitama, aga see kahjuks ei töötanud (The drive or Network connection […] is unavailable. Make sure the drive is properly inserted […]). Siin võis viga muidugi kasutajas olla - ei tea.
Kui kasutaja tehtud ja programm käivitatud, siis on edasiste kasutusjuhendi punktide järgimine üsna murevaba. Disaini poolest on loodud rakendus üks paremaid. Menüüd ja ikoonid on selged, ning lihtsasti eristatavad. Elementide paigutus on samuti loogiliselt teostatud.
 
== Koodi head omadused ==
 
Kuna disainil on tugev rõhk, siis suuremad kasutajaliidese osad on jaotatud eraldiseisvateks, ning nende stiil ei ole otse koodi sissekirjutatud, vaid selleks on kasutatud Application.Resources defineeritavaid stiilivõimalusi. Kood on üle terve projekti hästi kommenteeritud, seda muuhulgas nii XAML'is kui ka "kooditaguses". Samuti on meeldiv näha erinevaid wpf-elemente (radio-button/ drop-down/ jne). Paneele (stack/ grid jt) on samuti oskuslikult kasutatud.
Üldjuhul on suudetud hoida kenat koodistiili õigete nimetamisreeglite ja MVVM'le kohase projekti struktuuriga.
 
== Koodi puudused ==
 
Pisinorimisena võib välja tuua "String" ja "string" esinemised, samuti jäid silma üleliigsed using'ud. Lisaks on kasutatud nt Domain.CashregisterDBEntities, kui  using CashRegister.Domain on juba defineeritud, mis võimaldab kirjutada lihtsalt: CashregisterDBEntities. Suuremate projektide puhul ma saan aru sellisest kirjapildist (vältida kattumisi "package"-ite väljakirjutamisel), kuid see projekt ei küündi selliste mõõtmeteni; samuti ei ole selline nimetamine failiti ühtlane, mis paneb arvama, et see lihtsalt väike näpukas või VS-i üleliigne agarus on olnud.
Mõni päring andmebaasi näeb väga pikk ja lohisev välja. Mitmes kohas annaks päring osadeks tükeldada (nt nii mõneski kohas toLower()-id eelnevalt ära teha), mis omakorda parandaks oluliselt antud päringu loetavust.
Kaaluda oleks võinud ClientBO ja UserBO puhul baasmudeli kasutamist, sest need on suhteliselt sarnase iseloomuga. Võib-olla oleks nendest võinud teha isegi ühe andmebaasitabeli.
Üks suuremaid puudusi koodis MVVM seisukohalt on see, et kui kasutaja sisestab väljadesse mingit infot, siis on bindinguid kasutatud väga minimaalselt. Pea kõik tekstiväljad on saadetud edasi läbi Code behindi ja seega on seal liigselt loogikat, mille oleks saanud realiseerida vaatemudelis, saates väljadeinfo vaatest bindingu abil vaatemudelisse. Samas on bindinguid kenasti kasutatud vaatemudelist erinevatesse vaateelementidesse info kuvamisel.
 
== Kokkuvõte ==
 
Programm on silmale kena ja vastab enamusele kirjeldatud must-have nõutele ja osaliselt nii mõnelegi nice-to-have'ilegi. Arvestades projekti ajaraami siis on valminud täiesti korralik rakendus, mille mõned pisivead/-puudused on liikmete senist suurt tööd arvestades hõlpsasti lahendatavad.

Latest revision as of 00:13, 30 January 2017

Rakenduse kasutamise esmamulje

Tehtud on põhjalik kasutajajuhend rakenduse kasutamiseks. Kuigi peab tõdema, et kogu see protsess on kasutaja jaoks üsna ebamugavaks tehtud. Et programmi käivitada tuleb teha manuaalselt andmebaasis endale kasutaja, koos kõigi vajalike (NOT NULL) väljadega. See jätab kasutajale palju eksimisruumi (nt kuupäevade formaat jms) ja on lihtsalt ajakulukas. Programmiga oleks võinud kaasas olla .sql script mis vastava kasutaja programmi käivitades ise loob. Järgmises punktis on loodud kasutajale rakenduse .exe shortcut, mis peaks rakenduse mugavalt käivitama, aga see kahjuks ei töötanud (The drive or Network connection […] is unavailable. Make sure the drive is properly inserted […]). Siin võis viga muidugi kasutajas olla - ei tea. Kui kasutaja tehtud ja programm käivitatud, siis on edasiste kasutusjuhendi punktide järgimine üsna murevaba. Disaini poolest on loodud rakendus üks paremaid. Menüüd ja ikoonid on selged, ning lihtsasti eristatavad. Elementide paigutus on samuti loogiliselt teostatud.


Koodi head omadused

Kuna disainil on tugev rõhk, siis suuremad kasutajaliidese osad on jaotatud eraldiseisvateks, ning nende stiil ei ole otse koodi sissekirjutatud, vaid selleks on kasutatud Application.Resources defineeritavaid stiilivõimalusi. Kood on üle terve projekti hästi kommenteeritud, seda muuhulgas nii XAML'is kui ka "kooditaguses". Samuti on meeldiv näha erinevaid wpf-elemente (radio-button/ drop-down/ jne). Paneele (stack/ grid jt) on samuti oskuslikult kasutatud. Üldjuhul on suudetud hoida kenat koodistiili õigete nimetamisreeglite ja MVVM'le kohase projekti struktuuriga.


Koodi puudused

Pisinorimisena võib välja tuua "String" ja "string" esinemised, samuti jäid silma üleliigsed using'ud. Lisaks on kasutatud nt Domain.CashregisterDBEntities, kui using CashRegister.Domain on juba defineeritud, mis võimaldab kirjutada lihtsalt: CashregisterDBEntities. Suuremate projektide puhul ma saan aru sellisest kirjapildist (vältida kattumisi "package"-ite väljakirjutamisel), kuid see projekt ei küündi selliste mõõtmeteni; samuti ei ole selline nimetamine failiti ühtlane, mis paneb arvama, et see lihtsalt väike näpukas või VS-i üleliigne agarus on olnud. Mõni päring andmebaasi näeb väga pikk ja lohisev välja. Mitmes kohas annaks päring osadeks tükeldada (nt nii mõneski kohas toLower()-id eelnevalt ära teha), mis omakorda parandaks oluliselt antud päringu loetavust. Kaaluda oleks võinud ClientBO ja UserBO puhul baasmudeli kasutamist, sest need on suhteliselt sarnase iseloomuga. Võib-olla oleks nendest võinud teha isegi ühe andmebaasitabeli. Üks suuremaid puudusi koodis MVVM seisukohalt on see, et kui kasutaja sisestab väljadesse mingit infot, siis on bindinguid kasutatud väga minimaalselt. Pea kõik tekstiväljad on saadetud edasi läbi Code behindi ja seega on seal liigselt loogikat, mille oleks saanud realiseerida vaatemudelis, saates väljadeinfo vaatest bindingu abil vaatemudelisse. Samas on bindinguid kenasti kasutatud vaatemudelist erinevatesse vaateelementidesse info kuvamisel.


Kokkuvõte

Programm on silmale kena ja vastab enamusele kirjeldatud must-have nõutele ja osaliselt nii mõnelegi nice-to-have'ilegi. Arvestades projekti ajaraami siis on valminud täiesti korralik rakendus, mille mõned pisivead/-puudused on liikmete senist suurt tööd arvestades hõlpsasti lahendatavad.