Talk:Bomory - Revision history

Lteder: /* Analüüsi retsensioon */

2017-01-31T21:37:10Z

Analüüsi retsensioon

← Older revision		Revision as of 00:37, 1 February 2017
Line 2:		Line 2:

	Retsenseeris meeskond '''Kodune Raamatukogu'''.		Retsenseeris meeskond '''Kodune Raamatukogu'''.


	Rakendust planeerides on mõeldud läbi väga paljud rakenduse kasutusvõimalused. Samas jääb lugedes veel arusaamatuks, kuidas plaanitakse funktsionaalsused rakenduse lehekülgedele jaotada ning kui palju erinevaid lehekülgi plaanitakse teha. Funktsionaalsusi on küllaltki palju ning mitmed neist on dubleeritud, kuna raamatute ja filmide kuvamiseks/lisamiseks on eraldi vaated. Väga meeldis mulle mõte võimaluse korral kasutada ära GoodReadsi ja IMDB APIsid ning oli positiivne, et oldi end kurssi viidud GoodReadsi kodulehel kuvatava info kasutamise nõuetega.		Rakendust planeerides on mõeldud läbi väga paljud rakenduse kasutusvõimalused. Samas jääb lugedes veel arusaamatuks, kuidas plaanitakse funktsionaalsused rakenduse lehekülgedele jaotada ning kui palju erinevaid lehekülgi plaanitakse teha. Funktsionaalsusi on küllaltki palju ning mitmed neist on dubleeritud, kuna raamatute ja filmide kuvamiseks/lisamiseks on eraldi vaated. Väga meeldis mulle mõte võimaluse korral kasutada ära GoodReadsi ja IMDB APIsid ning oli positiivne, et oldi end kurssi viidud GoodReadsi kodulehel kuvatava info kasutamise nõuetega.


	Andmebaasi annaks optimeerida ning tabelite arvu vähendada. Kuna tabelid Book ja Movie on peaaegu identsed, saaks need iseenesest kokku panna, lisades sinna ühe rea määramaks, kas tegu on raamatu või filmiga. See võimaldaks liita kokku ka omamisseose tabelid (UsersMovie ja UsersBook).		Andmebaasi annaks optimeerida ning tabelite arvu vähendada. Kuna tabelid Book ja Movie on peaaegu identsed, saaks need iseenesest kokku panna, lisades sinna ühe rea määramaks, kas tegu on raamatu või filmiga. See võimaldaks liita kokku ka omamisseose tabelid (UsersMovie ja UsersBook).


	UsersBorrow tabel võiks välisvõtmete kaudu siduda omavahel tabelid User ja Book või User ja Movie, mida oleks jällegi veel lihtsam teostada, kui Book ja Movie oleksid koondatud samasse tabelisse. Hetkel UsersBorrow tabel suures osas dubleerib tabelite Book ja Movie andmeid. Samuti jääb UsersBorrow tabeli juures arusaamatuks, miks on kasutatud laenamisseoses kolme välja: BorrowedTo, BorrowedFrom ning UserId – tundub, et piisaks kahest (isiku Id, kes eset omab ning isiku Id, kes eseme laenutas).		UsersBorrow tabel võiks välisvõtmete kaudu siduda omavahel tabelid User ja Book või User ja Movie, mida oleks jällegi veel lihtsam teostada, kui Book ja Movie oleksid koondatud samasse tabelisse. Hetkel UsersBorrow tabel suures osas dubleerib tabelite Book ja Movie andmeid. Samuti jääb UsersBorrow tabeli juures arusaamatuks, miks on kasutatud laenamisseoses kolme välja: BorrowedTo, BorrowedFrom ning UserId – tundub, et piisaks kahest (isiku Id, kes eset omab ning isiku Id, kes eseme laenutas).


	Kokkuvõttes tundub rakendus väga ambitsioonikas paljude funktsionaalsuste kasutamise tõttu, mida on kindlasti lihtsam ellu viia, kui mõelda enne tegemist põhjalikult läbi kõik erinevad vaated ning millised funktsionaalsused saab panna samale leheküljele.		Kokkuvõttes tundub rakendus väga ambitsioonikas paljude funktsionaalsuste kasutamise tõttu, mida on kindlasti lihtsam ellu viia, kui mõelda enne tegemist põhjalikult läbi kõik erinevad vaated ning millised funktsionaalsused saab panna samale leheküljele.


			''31.01.17''

	=Lõpptoote retsensioon=		=Lõpptoote retsensioon=

Lteder: /* Lõpptoote retsensioon */

2017-01-31T21:36:10Z

Lõpptoote retsensioon

← Older revision		Revision as of 00:36, 1 February 2017
Line 1:		Line 1:
			=Analüüsi retsensioon=

			Retsenseeris meeskond '''Kodune Raamatukogu'''.

			Rakendust planeerides on mõeldud läbi väga paljud rakenduse kasutusvõimalused. Samas jääb lugedes veel arusaamatuks, kuidas plaanitakse funktsionaalsused rakenduse lehekülgedele jaotada ning kui palju erinevaid lehekülgi plaanitakse teha. Funktsionaalsusi on küllaltki palju ning mitmed neist on dubleeritud, kuna raamatute ja filmide kuvamiseks/lisamiseks on eraldi vaated. Väga meeldis mulle mõte võimaluse korral kasutada ära GoodReadsi ja IMDB APIsid ning oli positiivne, et oldi end kurssi viidud GoodReadsi kodulehel kuvatava info kasutamise nõuetega.

			Andmebaasi annaks optimeerida ning tabelite arvu vähendada. Kuna tabelid Book ja Movie on peaaegu identsed, saaks need iseenesest kokku panna, lisades sinna ühe rea määramaks, kas tegu on raamatu või filmiga. See võimaldaks liita kokku ka omamisseose tabelid (UsersMovie ja UsersBook).

			UsersBorrow tabel võiks välisvõtmete kaudu siduda omavahel tabelid User ja Book või User ja Movie, mida oleks jällegi veel lihtsam teostada, kui Book ja Movie oleksid koondatud samasse tabelisse. Hetkel UsersBorrow tabel suures osas dubleerib tabelite Book ja Movie andmeid. Samuti jääb UsersBorrow tabeli juures arusaamatuks, miks on kasutatud laenamisseoses kolme välja: BorrowedTo, BorrowedFrom ning UserId – tundub, et piisaks kahest (isiku Id, kes eset omab ning isiku Id, kes eseme laenutas).

			Kokkuvõttes tundub rakendus väga ambitsioonikas paljude funktsionaalsuste kasutamise tõttu, mida on kindlasti lihtsam ellu viia, kui mõelda enne tegemist põhjalikult läbi kõik erinevad vaated ning millised funktsionaalsused saab panna samale leheküljele.




	=Lõpptoote retsensioon=		=Lõpptoote retsensioon=

Ppomeran: /* Lõpptoote retsensioon */

2017-01-25T16:25:32Z

Lõpptoote retsensioon

← Older revision		Revision as of 19:25, 25 January 2017
Line 2:		Line 2:

	Retsenseeris meeskond '''Kassarakendus'''.		Retsenseeris meeskond '''Kassarakendus'''.


	Rakenduse kasutamise esmamulje		Rakenduse kasutamise esmamulje

Ppomeran: /* Lõpptoote retsensioon */

2017-01-25T16:25:12Z

Lõpptoote retsensioon

← Older revision		Revision as of 19:25, 25 January 2017
Line 7:		Line 7:
	Rakenduse kasutamine on mugav ja kõikide funktsioonide kasutamine on arusaadav. Vaadete navigatsioon on hea, lihtne ning stiil puhas. Meeskond on loonud rakenduse nagu ülesandepüstituses kirjeldatud.		Rakenduse kasutamine on mugav ja kõikide funktsioonide kasutamine on arusaadav. Vaadete navigatsioon on hea, lihtne ning stiil puhas. Meeskond on loonud rakenduse nagu ülesandepüstituses kirjeldatud.
	Arusaamatuks jääb, miks ei kuvata raamatute või filmide laenutamise kuupäeva. Samuti võiks olla teostatud laenatud raamatute/filmide dünaamiline lisamine enda raamatute/filmide nimistust, mitte ei peaks kõik andmed eraldi välja kirjutama. Objektorienteeritus peaks seda ju võimaldama.		Arusaamatuks jääb, miks ei kuvata raamatute või filmide laenutamise kuupäeva. Samuti võiks olla teostatud laenatud raamatute/filmide dünaamiline lisamine enda raamatute/filmide nimistust, mitte ei peaks kõik andmed eraldi välja kirjutama. Objektorienteeritus peaks seda ju võimaldama.


	Koodi head omadused		Koodi head omadused
Line 12:		Line 13:
	Üldjoontes on programm kirjutatud vastavalt projekti ülesehitamise nõuetele ja projektile on lähenetud objektorienteeritult. Meeskond on aru saanud MVVM raamistiku kasutamisest. Äriloogika ja presentatsiooniprojekti kirjutamine iseseisvate projektidena on mõistlik. Presentatsioonis on kood paigutatud vaadetesse ja vaatemudelitesse. Äriloogikas on kirjutatud vajalikud ärimudelite ja -teenuste klassid. Projekti andmebaasi mudel on mõistlik.		Üldjoontes on programm kirjutatud vastavalt projekti ülesehitamise nõuetele ja projektile on lähenetud objektorienteeritult. Meeskond on aru saanud MVVM raamistiku kasutamisest. Äriloogika ja presentatsiooniprojekti kirjutamine iseseisvate projektidena on mõistlik. Presentatsioonis on kood paigutatud vaadetesse ja vaatemudelitesse. Äriloogikas on kirjutatud vajalikud ärimudelite ja -teenuste klassid. Projekti andmebaasi mudel on mõistlik.
	Kood on jagatud klassidesse ning meetodid on enamasti kirjutatud just nii pikad, et täidaksid konkreetset eesmärki. Meetodite nimed vastavad nende funktsioonidele. Vaadetes on kasutatud andmete bindimist. Property-d kasutati viisil, mille võimalikkusest retsentseerijad polnud teadlikud – property-d toimisid ilma vastavate klassi olemimuutujate deklareerimiseta.		Kood on jagatud klassidesse ning meetodid on enamasti kirjutatud just nii pikad, et täidaksid konkreetset eesmärki. Meetodite nimed vastavad nende funktsioonidele. Vaadetes on kasutatud andmete bindimist. Property-d kasutati viisil, mille võimalikkusest retsentseerijad polnud teadlikud – property-d toimisid ilma vastavate klassi olemimuutujate deklareerimiseta.


	Koodi puudused		Koodi puudused
Line 19:		Line 21:
	Äriobjektides ja üksikutes teistes koodiosades kohtab põhjendamatut muutuja tüübi hardcode-mist, mis on arvatavasti seotud sellega, et andmebaasis lubatakse tühjasid väärtusid. Selline lähenemine pole väga hea stiil. Samuti on C#-s andmetüüpide kontrollimiseks paremad meetodid kui tavaline Try-Catch. Ei ole kasutatud erinevaid Try-Parse meetodeid.		Äriobjektides ja üksikutes teistes koodiosades kohtab põhjendamatut muutuja tüübi hardcode-mist, mis on arvatavasti seotud sellega, et andmebaasis lubatakse tühjasid väärtusid. Selline lähenemine pole väga hea stiil. Samuti on C#-s andmetüüpide kontrollimiseks paremad meetodid kui tavaline Try-Catch. Ei ole kasutatud erinevaid Try-Parse meetodeid.
	Enamustes äriteenuste meetodites, kus tagastatakse List, on ära unustatud LINQ meetod ToList(), mille asemel on kasutatud listi täitmiseks for-tsüklit. Samuti esineb töös mõttetut listide vahelist andmete ümber ladumist (listi andmete lisamine uude tühja listi). Andmeid eemaldatakse andmebaasi tabelitest Remove() meetodiga. Selles töös ei osutu see probleemiks, kuid andmete täieliku eelmaldamisel võib andmebaasis olevate seoste tõttu tekkida konflikt. Nii andmebaasis kui ka üleüldiselt oleks võinud filme ja raamatuid vaadata sama tüüpi objektidena. Kõik võiks olla ühes andmebaasitabelis.		Enamustes äriteenuste meetodites, kus tagastatakse List, on ära unustatud LINQ meetod ToList(), mille asemel on kasutatud listi täitmiseks for-tsüklit. Samuti esineb töös mõttetut listide vahelist andmete ümber ladumist (listi andmete lisamine uude tühja listi). Andmeid eemaldatakse andmebaasi tabelitest Remove() meetodiga. Selles töös ei osutu see probleemiks, kuid andmete täieliku eelmaldamisel võib andmebaasis olevate seoste tõttu tekkida konflikt. Nii andmebaasis kui ka üleüldiselt oleks võinud filme ja raamatuid vaadata sama tüüpi objektidena. Kõik võiks olla ühes andmebaasitabelis.


	Kokkuvõte		Kokkuvõte

	Programm töötab ja vastab projekti ülesehituse nõuetele. Midagi olulist ei ole puudu ega väga valesti. Kõik äramärgitud puudused on lahendatavad koodi silumisega.		Programm töötab ja vastab projekti ülesehituse nõuetele. Midagi olulist ei ole puudu ega väga valesti. Kõik äramärgitud puudused on lahendatavad koodi silumisega.


	25.01.2016		25.01.2016

Ppomeran: /* Lõpptoote retsensioon */

2017-01-25T16:24:53Z

Lõpptoote retsensioon

← Older revision		Revision as of 19:24, 25 January 2017
Line 4:		Line 4:

	Rakenduse kasutamise esmamulje		Rakenduse kasutamise esmamulje

	Rakenduse kasutamine on mugav ja kõikide funktsioonide kasutamine on arusaadav. Vaadete navigatsioon on hea, lihtne ning stiil puhas. Meeskond on loonud rakenduse nagu ülesandepüstituses kirjeldatud.		Rakenduse kasutamine on mugav ja kõikide funktsioonide kasutamine on arusaadav. Vaadete navigatsioon on hea, lihtne ning stiil puhas. Meeskond on loonud rakenduse nagu ülesandepüstituses kirjeldatud.
	Arusaamatuks jääb, miks ei kuvata raamatute või filmide laenutamise kuupäeva. Samuti võiks olla teostatud laenatud raamatute/filmide dünaamiline lisamine enda raamatute/filmide nimistust, mitte ei peaks kõik andmed eraldi välja kirjutama. Objektorienteeritus peaks seda ju võimaldama.		Arusaamatuks jääb, miks ei kuvata raamatute või filmide laenutamise kuupäeva. Samuti võiks olla teostatud laenatud raamatute/filmide dünaamiline lisamine enda raamatute/filmide nimistust, mitte ei peaks kõik andmed eraldi välja kirjutama. Objektorienteeritus peaks seda ju võimaldama.

	Koodi head omadused		Koodi head omadused

	Üldjoontes on programm kirjutatud vastavalt projekti ülesehitamise nõuetele ja projektile on lähenetud objektorienteeritult. Meeskond on aru saanud MVVM raamistiku kasutamisest. Äriloogika ja presentatsiooniprojekti kirjutamine iseseisvate projektidena on mõistlik. Presentatsioonis on kood paigutatud vaadetesse ja vaatemudelitesse. Äriloogikas on kirjutatud vajalikud ärimudelite ja -teenuste klassid. Projekti andmebaasi mudel on mõistlik.		Üldjoontes on programm kirjutatud vastavalt projekti ülesehitamise nõuetele ja projektile on lähenetud objektorienteeritult. Meeskond on aru saanud MVVM raamistiku kasutamisest. Äriloogika ja presentatsiooniprojekti kirjutamine iseseisvate projektidena on mõistlik. Presentatsioonis on kood paigutatud vaadetesse ja vaatemudelitesse. Äriloogikas on kirjutatud vajalikud ärimudelite ja -teenuste klassid. Projekti andmebaasi mudel on mõistlik.
	Kood on jagatud klassidesse ning meetodid on enamasti kirjutatud just nii pikad, et täidaksid konkreetset eesmärki. Meetodite nimed vastavad nende funktsioonidele. Vaadetes on kasutatud andmete bindimist. Property-d kasutati viisil, mille võimalikkusest retsentseerijad polnud teadlikud – property-d toimisid ilma vastavate klassi olemimuutujate deklareerimiseta.		Kood on jagatud klassidesse ning meetodid on enamasti kirjutatud just nii pikad, et täidaksid konkreetset eesmärki. Meetodite nimed vastavad nende funktsioonidele. Vaadetes on kasutatud andmete bindimist. Property-d kasutati viisil, mille võimalikkusest retsentseerijad polnud teadlikud – property-d toimisid ilma vastavate klassi olemimuutujate deklareerimiseta.

	Koodi puudused		Koodi puudused

	Koodikirjutamise stiil on kohati ebaühtlane. Mõndades klassides kirjutati property-d nagu eelmises peatükkis kirjeldatud, teistes mitte. See muudab bindingute lugemise segasemaks. Kohati jäi mulje, et vaatemudelites on property-d või olemimuutujaid liiga palju. Bindimiseks saab kasutada ka ainult ühte objekti. Näiteks bindides kasutada property Title asmele Movie.Title. Vaadete elementide samad omadused on igas elemendis eraldi välja kirjutatud. Stiile oleks võinud grupeerida kas App.xaml failis või sama vaate PageResources elemendis. Elementide omadused oleks võinud kirjutada üksteise alla, mis oleks parandanud koodi loetavust.		Koodikirjutamise stiil on kohati ebaühtlane. Mõndades klassides kirjutati property-d nagu eelmises peatükkis kirjeldatud, teistes mitte. See muudab bindingute lugemise segasemaks. Kohati jäi mulje, et vaatemudelites on property-d või olemimuutujaid liiga palju. Bindimiseks saab kasutada ka ainult ühte objekti. Näiteks bindides kasutada property Title asmele Movie.Title. Vaadete elementide samad omadused on igas elemendis eraldi välja kirjutatud. Stiile oleks võinud grupeerida kas App.xaml failis või sama vaate PageResources elemendis. Elementide omadused oleks võinud kirjutada üksteise alla, mis oleks parandanud koodi loetavust.
	Tihti kastutakse meetodi parameetrina mingi objekti ID-d, selle asemel, et kasutada objekti ennast. Sellisel juhul jääks meetodis võimalus kasutada ka objekti teisi omadusi. Samuti on töös kasutatud segamini äriobjekte kui domeeniobjekte. Presentatsioonikihis võiks piirduda äriobjektidega, mis tähendab, et vajaduse korral peab ärikihis muutma domeeniobjektid äriobjektideks või vastupidi.		Tihti kastutakse meetodi parameetrina mingi objekti ID-d, selle asemel, et kasutada objekti ennast. Sellisel juhul jääks meetodis võimalus kasutada ka objekti teisi omadusi. Samuti on töös kasutatud segamini äriobjekte kui domeeniobjekte. Presentatsioonikihis võiks piirduda äriobjektidega, mis tähendab, et vajaduse korral peab ärikihis muutma domeeniobjektid äriobjektideks või vastupidi.
Line 18:		Line 21:

	Kokkuvõte		Kokkuvõte

	Programm töötab ja vastab projekti ülesehituse nõuetele. Midagi olulist ei ole puudu ega väga valesti. Kõik äramärgitud puudused on lahendatavad koodi silumisega.		Programm töötab ja vastab projekti ülesehituse nõuetele. Midagi olulist ei ole puudu ega väga valesti. Kõik äramärgitud puudused on lahendatavad koodi silumisega.

	25.01.2016		25.01.2016

Ppomeran: /* Lõpptoote retsensioon */

2017-01-25T16:01:11Z

Lõpptoote retsensioon

← Older revision		Revision as of 19:01, 25 January 2017
Line 19:		Line 19:
	Kokkuvõte		Kokkuvõte
	Programm töötab ja vastab projekti ülesehituse nõuetele. Midagi olulist ei ole puudu ega väga valesti. Kõik äramärgitud puudused on lahendatavad koodi silumisega.		Programm töötab ja vastab projekti ülesehituse nõuetele. Midagi olulist ei ole puudu ega väga valesti. Kõik äramärgitud puudused on lahendatavad koodi silumisega.

			25.01.2016

Ppomeran: Created page with "=Lõpptoote retsensioon= Retsenseeris meeskond '''Kassarakendus'''. Rakenduse kasutamise esmamulje Rakenduse kasutamine on mugav ja kõikide funktsioonide kasutamine on arus..."

2017-01-25T16:00:29Z

Created page with "=Lõpptoote retsensioon= Retsenseeris meeskond '''Kassarakendus'''. Rakenduse kasutamise esmamulje Rakenduse kasutamine on mugav ja kõikide funktsioonide kasutamine on arus..."

New page

=Lõpptoote retsensioon=

Retsenseeris meeskond '''Kassarakendus'''.

Rakenduse kasutamise esmamulje
Rakenduse kasutamine on mugav ja kõikide funktsioonide kasutamine on arusaadav. Vaadete navigatsioon on hea, lihtne ning stiil puhas. Meeskond on loonud rakenduse nagu ülesandepüstituses kirjeldatud.
Arusaamatuks jääb, miks ei kuvata raamatute või filmide laenutamise kuupäeva. Samuti võiks olla teostatud laenatud raamatute/filmide dünaamiline lisamine enda raamatute/filmide nimistust, mitte ei peaks kõik andmed eraldi välja kirjutama. Objektorienteeritus peaks seda ju võimaldama.

Koodi head omadused
Üldjoontes on programm kirjutatud vastavalt projekti ülesehitamise nõuetele ja projektile on lähenetud objektorienteeritult. Meeskond on aru saanud MVVM raamistiku kasutamisest. Äriloogika ja presentatsiooniprojekti kirjutamine iseseisvate projektidena on mõistlik. Presentatsioonis on kood paigutatud vaadetesse ja vaatemudelitesse. Äriloogikas on kirjutatud vajalikud ärimudelite ja -teenuste klassid. Projekti andmebaasi mudel on mõistlik.
Kood on jagatud klassidesse ning meetodid on enamasti kirjutatud just nii pikad, et täidaksid konkreetset eesmärki. Meetodite nimed vastavad nende funktsioonidele. Vaadetes on kasutatud andmete bindimist. Property-d kasutati viisil, mille võimalikkusest retsentseerijad polnud teadlikud – property-d toimisid ilma vastavate klassi olemimuutujate deklareerimiseta.

Koodi puudused
Koodikirjutamise stiil on kohati ebaühtlane. Mõndades klassides kirjutati property-d nagu eelmises peatükkis kirjeldatud, teistes mitte. See muudab bindingute lugemise segasemaks. Kohati jäi mulje, et vaatemudelites on property-d või olemimuutujaid liiga palju. Bindimiseks saab kasutada ka ainult ühte objekti. Näiteks bindides kasutada property Title asmele Movie.Title. Vaadete elementide samad omadused on igas elemendis eraldi välja kirjutatud. Stiile oleks võinud grupeerida kas App.xaml failis või sama vaate PageResources elemendis. Elementide omadused oleks võinud kirjutada üksteise alla, mis oleks parandanud koodi loetavust.
Tihti kastutakse meetodi parameetrina mingi objekti ID-d, selle asemel, et kasutada objekti ennast. Sellisel juhul jääks meetodis võimalus kasutada ka objekti teisi omadusi. Samuti on töös kasutatud segamini äriobjekte kui domeeniobjekte. Presentatsioonikihis võiks piirduda äriobjektidega, mis tähendab, et vajaduse korral peab ärikihis muutma domeeniobjektid äriobjektideks või vastupidi.
Äriobjektides ja üksikutes teistes koodiosades kohtab põhjendamatut muutuja tüübi hardcode-mist, mis on arvatavasti seotud sellega, et andmebaasis lubatakse tühjasid väärtusid. Selline lähenemine pole väga hea stiil. Samuti on C#-s andmetüüpide kontrollimiseks paremad meetodid kui tavaline Try-Catch. Ei ole kasutatud erinevaid Try-Parse meetodeid.
Enamustes äriteenuste meetodites, kus tagastatakse List, on ära unustatud LINQ meetod ToList(), mille asemel on kasutatud listi täitmiseks for-tsüklit. Samuti esineb töös mõttetut listide vahelist andmete ümber ladumist (listi andmete lisamine uude tühja listi). Andmeid eemaldatakse andmebaasi tabelitest Remove() meetodiga. Selles töös ei osutu see probleemiks, kuid andmete täieliku eelmaldamisel võib andmebaasis olevate seoste tõttu tekkida konflikt. Nii andmebaasis kui ka üleüldiselt oleks võinud filme ja raamatuid vaadata sama tüüpi objektidena. Kõik võiks olla ühes andmebaasitabelis.

Kokkuvõte
Programm töötab ja vastab projekti ülesehituse nõuetele. Midagi olulist ei ole puudu ega väga valesti. Kõik äramärgitud puudused on lahendatavad koodi silumisega.