JRT - Revision history

Kkilgi: /* Meeskond CoverMe retsensioon meeskonnale SPOT */

2017-06-15T05:58:40Z

Meeskond CoverMe retsensioon meeskonnale SPOT

@@ Line 562: / Line 562: @@
 == Veebiteenuse Retsensioonid ==
 === Retsensioon meeskonnale "SPOT" ===
 Retsenseeritavaks tööks oli valitud tiimi SPOT veebiteenus, mis on seotud spordiklubide treeningute haldamisega. Esialgses andmebaasi skeemis oli plaanitud teha 16 tabelit, millest 4 on entitytega seotud. Projektis oli ära tehtud 12 domeeni mudeleid + entitytega seotud automaatselt. Mudelid tunduvad loogilised olla. On kasutatud propertid, mida andmebaasi ei salvestata, aga kalkuleeritakse jooksvalt. On kasutatud ka BaseEntity, milles on CreatedAt jne, ja kõik teised olemid pärinevad sellest, minu arust väga hea lahendus. Teenuse seadistatus, et tagastada jsoni igasuguste settingutega. API Routing pole muudetud, eriolukordade jaoks kasutatakse routingu atribuutides. Rakenduses on realiseeritud Seed meetod, mis väärtustab andmebaasi testandmetega. On näha, et testandmete täitmisel on kasutatud üks väline xml fail, faili töötlemises on kasutatud nii foreach tsükleid, kui ka LINQ avaldisi. Oleks hea kui paljudes kohtades null reference exceptioni vältimiseks teeks checki, aga muidu kui võtta arvesse, et see XML ei muutu kunagi, siis tehtud/pakutud variant ka sobib. Data access layer on ilusasti tehtud, iga olemi jaoks tehtud repositoorium, mis oma korda implementeerib interface’i. Repositooriumide päringul on ka realiseeritud singletoni muster. Järgmisel tasemel on tehtud UOW, kus on kasutusel nii Custom Repo küsimine, kui ka Standard. NLOg logimine on ka ilusasti implementeeritud. Üldiselt DAL projekti vaadates tekib tunne, et tiim on seda läbi töötanud ja ilusasti häid praktikaid kasutades tegi ära. Järgmine projekt on “BL”, kohe näha, et projekt on ilusasti struktureeritud, kasutatakse factoreid ja serviceid, mil omakorda implementeerivad interface. Data Transfer objektides ei ole miksimist domeen olemitega, mis on hästi, kuna selline olukord tekitaks “lazy loading”-uga, et kõik seosed ja andmed tuleksid andmebaasist, mida pole vaja. DTO-des ei ole kasutatud atribuute, mis sõltuvalt olukorrast võib olla halb, kuna puudub igasugune kontroll mida kasutaja saadab teenuse peale. Nagu ennem oli öeldud, et interfacid on kasutusel, aga objekti loomisel ei kasutata DI mootorit, vaid luuakse otse new keyword’iga. Andmebaasi salvestamine käib läbi UOW. Kõik DTO-d, serviced ja factoryd tunduvad läbimõeldud. Solution’is eksisteerib projekt nimega “ConsoleApp” tundub, et tiim kasutas seda oma veebiteenuse testimiseks. Järgmine projekt on DataAnnotations, milles olemas ainuke klass “Precision”, Internetis otsides ja koodi vaadates, sain teada, et seda kasutatakse decimal täpsuse kindlaks tegemiseks ja sellist valmis lahenduse .net-is pole. SPOT tiimi solution’is ma kahjuks ei leidnud mitte ühtegi kohta kus seda kasutatakse. Järgmine projekt on Identity, kus on kõik olemid identity’ga seotud ja vajalikud services. Järgmine projekt ‘’Interfaces’’, kus hoitakse peaaegu kõik interfacid. Ja viimane projekt on “WebApi”, mis hoiab endas veebiteenuste kontrollereid, vaateid, scripte ja teisi faile. Kontrollerist on näha, et tiim tegi ümber Entity Useri primaarse võtme stringist integeri. On kasutusel Authorize atribuudid, mis piiravad liigipääsu erinevatele kontrolleritele/meetoditele. Samuti veebiteenuses eksisteerivad erinevad rollid (Admin ja treener), neid ka kasutatakse Authorize atribuutides. Samuti kontrollerites on kasutusel GET, POST, PUT ja DELETE päringute päised. Kontrollerites on implementeeritud sünkroonne lähenemine (pole kusagil olemas async võtmesõna). Kui rääkida tööst üldiselt, siis kohe näha, et tiim tegi suure töö (see pole mahulises mõttes lõpetatud, aga kogu baas on olemas, jäänud ainult DTO-de tegemine ja nende käsitlemine). Ainukesed puudused, mida ma näen, on DTO-des atribuutide puudumine. Aga muidu tuli välja ilus, loogiliselt struktureeritud veebiteenus.

Kkilgi: /* Meeskond CoverMe retsensioon meeskonnale SPOT */

2017-06-15T05:57:36Z

Meeskond CoverMe retsensioon meeskonnale SPOT

← Older revision		Revision as of 08:57, 15 June 2017
Line 570:		Line 570:

	Veebiteenuse struktuur on üles ehitatud kihiliselt, mis võimaldab vajadusel süsteemi osasid lihtsamini muuta, täiendada ja vajadusel välja vahetada. Kihid on jaotatud järgmiselt:		Veebiteenuse struktuur on üles ehitatud kihiliselt, mis võimaldab vajadusel süsteemi osasid lihtsamini muuta, täiendada ja vajadusel välja vahetada. Kihid on jaotatud järgmiselt:

	BL - sisaldab DTO-sid ja nende koostamiseks vajalikke Factoreid. Samuti on siin Service klassid, milles on kirjas kõik päringud andmebaasist (Get mitmesugustes variantides, Add, Edit, Delete). Lisaks tavalistele CRUD meetoditele on tehtud ka spetsiifilisemad päringud , näiteks GetByIdForUser jne. Päringuid tehakse uow-de kaudu. Service’tele ja Factory’tele on loodud Interface’d.		BL - sisaldab DTO-sid ja nende koostamiseks vajalikke Factoreid. Samuti on siin Service klassid, milles on kirjas kõik päringud andmebaasist (Get mitmesugustes variantides, Add, Edit, Delete). Lisaks tavalistele CRUD meetoditele on tehtud ka spetsiifilisemad päringud , näiteks GetByIdForUser jne. Päringuid tehakse uow-de kaudu. Service’tele ja Factory’tele on loodud Interface’d.

	DAL - kasutatakse EFRepositoryFactory ja EFRepositoryProvidery põhimõtteid. DbInitializeris antakse ette lähteandmete seed’imine. Repositooriumid on omaette kaustas, kuhu on lisaks EFRepository-st päritud meetoditele juurde kirjutatud palju erinevaid meetodeid funktsionaalsuse täiendamiseks.		DAL - kasutatakse EFRepositoryFactory ja EFRepositoryProvidery põhimõtteid. DbInitializeris antakse ette lähteandmete seed’imine. Repositooriumid on omaette kaustas, kuhu on lisaks EFRepository-st päritud meetoditele juurde kirjutatud palju erinevaid meetodeid funktsionaalsuse täiendamiseks.

	Domain - andmebaasi mudelis on kokku 12 olemit, mis on nõuetele vastav. Üldine andmebaasimudeli ülesehitus on loogiline ning listid on algselt väärtustatud, mis tagab selle, et ei pea NullReference Exceptione kontrollima. Vajalikesse kohtadesse on annotatsioonid juurde lisatud ja nendega ei ole üle pingutatud, et süsteemi liiga kirjuks ajada. Tõstame esile asjaolu, et kasutatud on Base Entity’t, millest kõik ülejäänud olemid pärinevad. See ühtlustab rakenduse koodi ja on üldse väga hea mõte. Kasutatud on palju nullable tüüpi muutujaid, mis on antud juhul õigustatud, andes andmete sisestamisel paindlikkust, samas lisades mõneti riskantsust.		Domain - andmebaasi mudelis on kokku 12 olemit, mis on nõuetele vastav. Üldine andmebaasimudeli ülesehitus on loogiline ning listid on algselt väärtustatud, mis tagab selle, et ei pea NullReference Exceptione kontrollima. Vajalikesse kohtadesse on annotatsioonid juurde lisatud ja nendega ei ole üle pingutatud, et süsteemi liiga kirjuks ajada. Tõstame esile asjaolu, et kasutatud on Base Entity’t, millest kõik ülejäänud olemid pärinevad. See ühtlustab rakenduse koodi ja on üldse väga hea mõte. Kasutatud on palju nullable tüüpi muutujaid, mis on antud juhul õigustatud, andes andmete sisestamisel paindlikkust, samas lisades mõneti riskantsust.
	Interfaces - Kõikide repositooriumide jaoks on loodud ka interface´d. Samuti leidub seal UOW jaoks interface.
			Interfaces - Kõikide repositooriumide jaoks on loodud ka interface´d. Samuti leidub seal UOW jaoks interface.

	WebApi - Kokku on kasutusel 6 kontrollerit, milles on realiseeritud CRUD meetodid koos mõne spetsiifilisema meetodiga (näiteks GetFilteredForPeriod). Kontrollerid saavad oma sisu vastavatest service’itest. Identity rakendamiseks on kontrollerite meetoditel kasutatatud Authorize annotatsioone. Samuti on läbi mõeldud, et mõnda meetodit on autoriseeritud kasutama ainult “Admin”-kasutaja. Näiteks ainult “Admin”, saab salvestada treenereid andmebaasi. Kontrollerites on kenasti kasutatud erinevaid Http-staatuskoode, mitte ainult Ok(), vaid ka Forbidden(), NotFound() jne. Samuti kasutatakse edukalt sõltuvuste süstimist (Dependency Injection). Kasutatud on OAuth bearer token authentication’it.		WebApi - Kokku on kasutusel 6 kontrollerit, milles on realiseeritud CRUD meetodid koos mõne spetsiifilisema meetodiga (näiteks GetFilteredForPeriod). Kontrollerid saavad oma sisu vastavatest service’itest. Identity rakendamiseks on kontrollerite meetoditel kasutatatud Authorize annotatsioone. Samuti on läbi mõeldud, et mõnda meetodit on autoriseeritud kasutama ainult “Admin”-kasutaja. Näiteks ainult “Admin”, saab salvestada treenereid andmebaasi. Kontrollerites on kenasti kasutatud erinevaid Http-staatuskoode, mitte ainult Ok(), vaid ka Forbidden(), NotFound() jne. Samuti kasutatakse edukalt sõltuvuste süstimist (Dependency Injection). Kasutatud on OAuth bearer token authentication’it.

Line 579:		Line 584:

	Kokkuvõtteks võib öelda, et tegemist on väga hästi kavandatud ja realiseeritud veebiteenusega ja meeskonnaliikmete panus on olnud märkimisväärne, eriti arvestades seda, et tegemist oli vaid kahe liikmega.		Kokkuvõtteks võib öelda, et tegemist on väga hästi kavandatud ja realiseeritud veebiteenusega ja meeskonnaliikmete panus on olnud märkimisväärne, eriti arvestades seda, et tegemist oli vaid kahe liikmega.


	=== Retsensioon meeskonnale "SPOT" ===		=== Retsensioon meeskonnale "SPOT" ===

	Retsenseeritavaks tööks oli valitud tiimi SPOT veebiteenus, mis on seotud spordiklubide treeningute haldamisega. Esialgses andmebaasi skeemis oli plaanitud teha 16 tabelit, millest 4 on entitytega seotud. Projektis oli ära tehtud 12 domeeni mudeleid + entitytega seotud automaatselt. Mudelid tunduvad loogilised olla. On kasutatud propertid, mida andmebaasi ei salvestata, aga kalkuleeritakse jooksvalt. On kasutatud ka BaseEntity, milles on CreatedAt jne, ja kõik teised olemid pärinevad sellest, minu arust väga hea lahendus. Teenuse seadistatus, et tagastada jsoni igasuguste settingutega. API Routing pole muudetud, eriolukordade jaoks kasutatakse routingu atribuutides. Rakenduses on realiseeritud Seed meetod, mis väärtustab andmebaasi testandmetega. On näha, et testandmete täitmisel on kasutatud üks väline xml fail, faili töötlemises on kasutatud nii foreach tsükleid, kui ka LINQ avaldisi. Oleks hea kui paljudes kohtades null reference exceptioni vältimiseks teeks checki, aga muidu kui võtta arvesse, et see XML ei muutu kunagi, siis tehtud/pakutud variant ka sobib. Data access layer on ilusasti tehtud, iga olemi jaoks tehtud repositoorium, mis oma korda implementeerib interface’i. Repositooriumide päringul on ka realiseeritud singletoni muster. Järgmisel tasemel on tehtud UOW, kus on kasutusel nii Custom Repo küsimine, kui ka Standard. NLOg logimine on ka ilusasti implementeeritud. Üldiselt DAL projekti vaadates tekib tunne, et tiim on seda läbi töötanud ja ilusasti häid praktikaid kasutades tegi ära. Järgmine projekt on “BL”, kohe näha, et projekt on ilusasti struktureeritud, kasutatakse factoreid ja serviceid, mil omakorda implementeerivad interface. Data Transfer objektides ei ole miksimist domeen olemitega, mis on hästi, kuna selline olukord tekitaks “lazy loading”-uga, et kõik seosed ja andmed tuleksid andmebaasist, mida pole vaja. DTO-des ei ole kasutatud atribuute, mis sõltuvalt olukorrast võib olla halb, kuna puudub igasugune kontroll mida kasutaja saadab teenuse peale. Nagu ennem oli öeldud, et interfacid on kasutusel, aga objekti loomisel ei kasutata DI mootorit, vaid luuakse otse new keyword’iga. Andmebaasi salvestamine käib läbi UOW. Kõik DTO-d, serviced ja factoryd tunduvad läbimõeldud. Solution’is eksisteerib projekt nimega “ConsoleApp” tundub, et tiim kasutas seda oma veebiteenuse testimiseks. Järgmine projekt on DataAnnotations, milles olemas ainuke klass “Precision”, Internetis otsides ja koodi vaadates, sain teada, et seda kasutatakse decimal täpsuse kindlaks tegemiseks ja sellist valmis lahenduse .net-is pole. SPOT tiimi solution’is ma kahjuks ei leidnud mitte ühtegi kohta kus seda kasutatakse. Järgmine projekt on Identity, kus on kõik olemid identity’ga seotud ja vajalikud services. Järgmine projekt ‘’Interfaces’’, kus hoitakse peaaegu kõik interfacid. Ja viimane projekt on “WebApi”, mis hoiab endas veebiteenuste kontrollereid, vaateid, scripte ja teisi faile. Kontrollerist on näha, et tiim tegi ümber Entity Useri primaarse võtme stringist integeri. On kasutusel Authorize atribuudid, mis piiravad liigipääsu erinevatele kontrolleritele/meetoditele. Samuti veebiteenuses eksisteerivad erinevad rollid (Admin ja treener), neid ka kasutatakse Authorize atribuutides. Samuti kontrollerites on kasutusel GET, POST, PUT ja DELETE päringute päised. Kontrollerites on implementeeritud sünkroonne lähenemine (pole kusagil olemas async võtmesõna). Kui rääkida tööst üldiselt, siis kohe näha, et tiim tegi suure töö (see pole mahulises mõttes lõpetatud, aga kogu baas on olemas, jäänud ainult DTO-de tegemine ja nende käsitlemine). Ainukesed puudused, mida ma näen, on DTO-des atribuutide puudumine. Aga muidu tuli välja ilus, loogiliselt struktureeritud veebiteenus.		Retsenseeritavaks tööks oli valitud tiimi SPOT veebiteenus, mis on seotud spordiklubide treeningute haldamisega. Esialgses andmebaasi skeemis oli plaanitud teha 16 tabelit, millest 4 on entitytega seotud. Projektis oli ära tehtud 12 domeeni mudeleid + entitytega seotud automaatselt. Mudelid tunduvad loogilised olla. On kasutatud propertid, mida andmebaasi ei salvestata, aga kalkuleeritakse jooksvalt. On kasutatud ka BaseEntity, milles on CreatedAt jne, ja kõik teised olemid pärinevad sellest, minu arust väga hea lahendus. Teenuse seadistatus, et tagastada jsoni igasuguste settingutega. API Routing pole muudetud, eriolukordade jaoks kasutatakse routingu atribuutides. Rakenduses on realiseeritud Seed meetod, mis väärtustab andmebaasi testandmetega. On näha, et testandmete täitmisel on kasutatud üks väline xml fail, faili töötlemises on kasutatud nii foreach tsükleid, kui ka LINQ avaldisi. Oleks hea kui paljudes kohtades null reference exceptioni vältimiseks teeks checki, aga muidu kui võtta arvesse, et see XML ei muutu kunagi, siis tehtud/pakutud variant ka sobib. Data access layer on ilusasti tehtud, iga olemi jaoks tehtud repositoorium, mis oma korda implementeerib interface’i. Repositooriumide päringul on ka realiseeritud singletoni muster. Järgmisel tasemel on tehtud UOW, kus on kasutusel nii Custom Repo küsimine, kui ka Standard. NLOg logimine on ka ilusasti implementeeritud. Üldiselt DAL projekti vaadates tekib tunne, et tiim on seda läbi töötanud ja ilusasti häid praktikaid kasutades tegi ära. Järgmine projekt on “BL”, kohe näha, et projekt on ilusasti struktureeritud, kasutatakse factoreid ja serviceid, mil omakorda implementeerivad interface. Data Transfer objektides ei ole miksimist domeen olemitega, mis on hästi, kuna selline olukord tekitaks “lazy loading”-uga, et kõik seosed ja andmed tuleksid andmebaasist, mida pole vaja. DTO-des ei ole kasutatud atribuute, mis sõltuvalt olukorrast võib olla halb, kuna puudub igasugune kontroll mida kasutaja saadab teenuse peale. Nagu ennem oli öeldud, et interfacid on kasutusel, aga objekti loomisel ei kasutata DI mootorit, vaid luuakse otse new keyword’iga. Andmebaasi salvestamine käib läbi UOW. Kõik DTO-d, serviced ja factoryd tunduvad läbimõeldud. Solution’is eksisteerib projekt nimega “ConsoleApp” tundub, et tiim kasutas seda oma veebiteenuse testimiseks. Järgmine projekt on DataAnnotations, milles olemas ainuke klass “Precision”, Internetis otsides ja koodi vaadates, sain teada, et seda kasutatakse decimal täpsuse kindlaks tegemiseks ja sellist valmis lahenduse .net-is pole. SPOT tiimi solution’is ma kahjuks ei leidnud mitte ühtegi kohta kus seda kasutatakse. Järgmine projekt on Identity, kus on kõik olemid identity’ga seotud ja vajalikud services. Järgmine projekt ‘’Interfaces’’, kus hoitakse peaaegu kõik interfacid. Ja viimane projekt on “WebApi”, mis hoiab endas veebiteenuste kontrollereid, vaateid, scripte ja teisi faile. Kontrollerist on näha, et tiim tegi ümber Entity Useri primaarse võtme stringist integeri. On kasutusel Authorize atribuudid, mis piiravad liigipääsu erinevatele kontrolleritele/meetoditele. Samuti veebiteenuses eksisteerivad erinevad rollid (Admin ja treener), neid ka kasutatakse Authorize atribuutides. Samuti kontrollerites on kasutusel GET, POST, PUT ja DELETE päringute päised. Kontrollerites on implementeeritud sünkroonne lähenemine (pole kusagil olemas async võtmesõna). Kui rääkida tööst üldiselt, siis kohe näha, et tiim tegi suure töö (see pole mahulises mõttes lõpetatud, aga kogu baas on olemas, jäänud ainult DTO-de tegemine ja nende käsitlemine). Ainukesed puudused, mida ma näen, on DTO-des atribuutide puudumine. Aga muidu tuli välja ilus, loogiliselt struktureeritud veebiteenus.

Kkilgi: /* Veebiteenuse Retsensioonid */

2017-06-15T05:55:31Z

Veebiteenuse Retsensioonid

@@ Line 562: / Line 562: @@
 == Veebiteenuse Retsensioonid ==
 === Retsensioon meeskonnale "SPOT" ===
 Retsenseeritavaks tööks oli valitud tiimi SPOT veebiteenus, mis on seotud spordiklubide treeningute haldamisega. Esialgses andmebaasi skeemis oli plaanitud teha 16 tabelit, millest 4 on entitytega seotud. Projektis oli ära tehtud 12 domeeni mudeleid + entitytega seotud automaatselt. Mudelid tunduvad loogilised olla. On kasutatud propertid, mida andmebaasi ei salvestata, aga kalkuleeritakse jooksvalt. On kasutatud ka BaseEntity, milles on CreatedAt jne, ja kõik teised olemid pärinevad sellest, minu arust väga hea lahendus. Teenuse seadistatus, et tagastada jsoni igasuguste settingutega. API Routing pole muudetud, eriolukordade jaoks kasutatakse routingu atribuutides. Rakenduses on realiseeritud Seed meetod, mis väärtustab andmebaasi testandmetega. On näha, et testandmete täitmisel on kasutatud üks väline xml fail, faili töötlemises on kasutatud nii foreach tsükleid, kui ka LINQ avaldisi. Oleks hea kui paljudes kohtades null reference exceptioni vältimiseks teeks checki, aga muidu kui võtta arvesse, et see XML ei muutu kunagi, siis tehtud/pakutud variant ka sobib. Data access layer on ilusasti tehtud, iga olemi jaoks tehtud repositoorium, mis oma korda implementeerib interface’i. Repositooriumide päringul on ka realiseeritud singletoni muster. Järgmisel tasemel on tehtud UOW, kus on kasutusel nii Custom Repo küsimine, kui ka Standard. NLOg logimine on ka ilusasti implementeeritud. Üldiselt DAL projekti vaadates tekib tunne, et tiim on seda läbi töötanud ja ilusasti häid praktikaid kasutades tegi ära. Järgmine projekt on “BL”, kohe näha, et projekt on ilusasti struktureeritud, kasutatakse factoreid ja serviceid, mil omakorda implementeerivad interface. Data Transfer objektides ei ole miksimist domeen olemitega, mis on hästi, kuna selline olukord tekitaks “lazy loading”-uga, et kõik seosed ja andmed tuleksid andmebaasist, mida pole vaja. DTO-des ei ole kasutatud atribuute, mis sõltuvalt olukorrast võib olla halb, kuna puudub igasugune kontroll mida kasutaja saadab teenuse peale. Nagu ennem oli öeldud, et interfacid on kasutusel, aga objekti loomisel ei kasutata DI mootorit, vaid luuakse otse new keyword’iga. Andmebaasi salvestamine käib läbi UOW. Kõik DTO-d, serviced ja factoryd tunduvad läbimõeldud. Solution’is eksisteerib projekt nimega “ConsoleApp” tundub, et tiim kasutas seda oma veebiteenuse testimiseks. Järgmine projekt on DataAnnotations, milles olemas ainuke klass “Precision”, Internetis otsides ja koodi vaadates, sain teada, et seda kasutatakse decimal täpsuse kindlaks tegemiseks ja sellist valmis lahenduse .net-is pole. SPOT tiimi solution’is ma kahjuks ei leidnud mitte ühtegi kohta kus seda kasutatakse. Järgmine projekt on Identity, kus on kõik olemid identity’ga seotud ja vajalikud services. Järgmine projekt ‘’Interfaces’’, kus hoitakse peaaegu kõik interfacid. Ja viimane projekt on “WebApi”, mis hoiab endas veebiteenuste kontrollereid, vaateid, scripte ja teisi faile. Kontrollerist on näha, et tiim tegi ümber Entity Useri primaarse võtme stringist integeri. On kasutusel Authorize atribuudid, mis piiravad liigipääsu erinevatele kontrolleritele/meetoditele. Samuti veebiteenuses eksisteerivad erinevad rollid (Admin ja treener), neid ka kasutatakse Authorize atribuutides. Samuti kontrollerites on kasutusel GET, POST, PUT ja DELETE päringute päised. Kontrollerites on implementeeritud sünkroonne lähenemine (pole kusagil olemas async võtmesõna). Kui rääkida tööst üldiselt, siis kohe näha, et tiim tegi suure töö (see pole mahulises mõttes lõpetatud, aga kogu baas on olemas, jäänud ainult DTO-de tegemine ja nende käsitlemine). Ainukesed puudused, mida ma näen, on DTO-des atribuutide puudumine. Aga muidu tuli välja ilus, loogiliselt struktureeritud veebiteenus.

Jgavrilo at 20:35, 14 June 2017

2017-06-14T20:35:28Z

← Older revision		Revision as of 23:35, 14 June 2017
Line 560:		Line 560:

	Tööd on küll esitatud ja vaeva nähtud, kuid kõik lahenduste aspektid ei vasta siiski õppejõu poolt ettenähtud nõuetele. Lisaks on probleeme osade koodide valideerumisega (XSD ja üks XSLT). Need asjad tasuks rakenduse edasist arendamist silmas pidades üle vaadata.		Tööd on küll esitatud ja vaeva nähtud, kuid kõik lahenduste aspektid ei vasta siiski õppejõu poolt ettenähtud nõuetele. Lisaks on probleeme osade koodide valideerumisega (XSD ja üks XSLT). Need asjad tasuks rakenduse edasist arendamist silmas pidades üle vaadata.

			== Veebiteenuse Retsensioonid ==
			=== Retsensioon meeskonnale "SPOT" ===

			Retsenseeritavaks tööks oli valitud tiimi SPOT veebiteenus, mis on seotud spordiklubide treeningute haldamisega. Esialgses andmebaasi skeemis oli plaanitud teha 16 tabelit, millest 4 on entitytega seotud. Projektis oli ära tehtud 12 domeeni mudeleid + entitytega seotud automaatselt. Mudelid tunduvad loogilised olla. On kasutatud propertid, mida andmebaasi ei salvestata, aga kalkuleeritakse jooksvalt. On kasutatud ka BaseEntity, milles on CreatedAt jne, ja kõik teised olemid pärinevad sellest, minu arust väga hea lahendus. Teenuse seadistatus, et tagastada jsoni igasuguste settingutega. API Routing pole muudetud, eriolukordade jaoks kasutatakse routingu atribuutides. Rakenduses on realiseeritud Seed meetod, mis väärtustab andmebaasi testandmetega. On näha, et testandmete täitmisel on kasutatud üks väline xml fail, faili töötlemises on kasutatud nii foreach tsükleid, kui ka LINQ avaldisi. Oleks hea kui paljudes kohtades null reference exceptioni vältimiseks teeks checki, aga muidu kui võtta arvesse, et see XML ei muutu kunagi, siis tehtud/pakutud variant ka sobib. Data access layer on ilusasti tehtud, iga olemi jaoks tehtud repositoorium, mis oma korda implementeerib interface’i. Repositooriumide päringul on ka realiseeritud singletoni muster. Järgmisel tasemel on tehtud UOW, kus on kasutusel nii Custom Repo küsimine, kui ka Standard. NLOg logimine on ka ilusasti implementeeritud. Üldiselt DAL projekti vaadates tekib tunne, et tiim on seda läbi töötanud ja ilusasti häid praktikaid kasutades tegi ära. Järgmine projekt on “BL”, kohe näha, et projekt on ilusasti struktureeritud, kasutatakse factoreid ja serviceid, mil omakorda implementeerivad interface. Data Transfer objektides ei ole miksimist domeen olemitega, mis on hästi, kuna selline olukord tekitaks “lazy loading”-uga, et kõik seosed ja andmed tuleksid andmebaasist, mida pole vaja. DTO-des ei ole kasutatud atribuute, mis sõltuvalt olukorrast võib olla halb, kuna puudub igasugune kontroll mida kasutaja saadab teenuse peale. Nagu ennem oli öeldud, et interfacid on kasutusel, aga objekti loomisel ei kasutata DI mootorit, vaid luuakse otse new keyword’iga. Andmebaasi salvestamine käib läbi UOW. Kõik DTO-d, serviced ja factoryd tunduvad läbimõeldud. Solution’is eksisteerib projekt nimega “ConsoleApp” tundub, et tiim kasutas seda oma veebiteenuse testimiseks. Järgmine projekt on DataAnnotations, milles olemas ainuke klass “Precision”, Internetis otsides ja koodi vaadates, sain teada, et seda kasutatakse decimal täpsuse kindlaks tegemiseks ja sellist valmis lahenduse .net-is pole. SPOT tiimi solution’is ma kahjuks ei leidnud mitte ühtegi kohta kus seda kasutatakse. Järgmine projekt on Identity, kus on kõik olemid identity’ga seotud ja vajalikud services. Järgmine projekt ‘’Interfaces’’, kus hoitakse peaaegu kõik interfacid. Ja viimane projekt on “WebApi”, mis hoiab endas veebiteenuste kontrollereid, vaateid, scripte ja teisi faile. Kontrollerist on näha, et tiim tegi ümber Entity Useri primaarse võtme stringist integeri. On kasutusel Authorize atribuudid, mis piiravad liigipääsu erinevatele kontrolleritele/meetoditele. Samuti veebiteenuses eksisteerivad erinevad rollid (Admin ja treener), neid ka kasutatakse Authorize atribuutides. Samuti kontrollerites on kasutusel GET, POST, PUT ja DELETE päringute päised. Kontrollerites on implementeeritud sünkroonne lähenemine (pole kusagil olemas async võtmesõna). Kui rääkida tööst üldiselt, siis kohe näha, et tiim tegi suure töö (see pole mahulises mõttes lõpetatud, aga kogu baas on olemas, jäänud ainult DTO-de tegemine ja nende käsitlemine). Ainukesed puudused, mida ma näen, on DTO-des atribuutide puudumine. Aga muidu tuli välja ilus, loogiliselt struktureeritud veebiteenus.

Ruusjarv: /* Blog */

2017-06-12T07:46:24Z

Blog

← Older revision		Revision as of 10:46, 12 June 2017
Line 11:		Line 11:
	26.03.2017 - Retsenseerimine<br>		26.03.2017 - Retsenseerimine<br>
	01.05.2017 - Analüüsi valmimine ja lisamine koos andmebaasi failiga<br>		01.05.2017 - Analüüsi valmimine ja lisamine koos andmebaasi failiga<br>
			11.06.2017 - Projekti faili lisamine

	= Tööd =		= Tööd =

Ruusjarv: /* Projekti fail */

2017-06-11T14:58:15Z

Projekti fail

← Older revision		Revision as of 17:58, 11 June 2017
Line 474:		Line 474:
	===Projekti fail===		===Projekti fail===

	Projekt tehtud siis kahe liikme poolt: Riho Uusjärv ja Jevgeni Gavrilov		Projekt tehtud siis kahe liikme poolt: Riho Uusjärv ja Jevgeni Gavrilov ja projekti fail asub aadressil: https://drive.google.com/open?id=0B3nb9qMzOVSuQ1NOdk02bmhUT3c
	https://drive.google.com/open?id=0B3nb9qMzOVSuQ1NOdk02bmhUT3c

	=Retsensioonid=		=Retsensioonid=

Ruusjarv: /* Projekti fail */

2017-06-11T14:57:27Z

Projekti fail

← Older revision		Revision as of 17:57, 11 June 2017
Line 475:		Line 475:

	Projekt tehtud siis kahe liikme poolt: Riho Uusjärv ja Jevgeni Gavrilov		Projekt tehtud siis kahe liikme poolt: Riho Uusjärv ja Jevgeni Gavrilov
	https://drive.google.com/~~drive/folders/0B3nb9qMzOVSuQ1NOdk02bmhUT3c~~?~~usp~~=~~sharing~~		https://drive.google.com/open?id=0B3nb9qMzOVSuQ1NOdk02bmhUT3c

	=Retsensioonid=		=Retsensioonid=

Ruusjarv: faili lin

2017-06-11T14:55:21Z

faili lin

← Older revision		Revision as of 17:55, 11 June 2017
Line 471:		Line 471:

	[[File:AB_GYM4.PNG]]		[[File:AB_GYM4.PNG]]

			===Projekti fail===

			Projekt tehtud siis kahe liikme poolt: Riho Uusjärv ja Jevgeni Gavrilov
			https://drive.google.com/drive/folders/0B3nb9qMzOVSuQ1NOdk02bmhUT3c?usp=sharing

	=Retsensioonid=		=Retsensioonid=

Ruusjarv: /* Andmebaasi kirjeldus */

2017-05-09T19:41:05Z

Andmebaasi kirjeldus

← Older revision		Revision as of 22:41, 9 May 2017
Line 470:		Line 470:


	[[File:~~AB_GYM3~~.PNG]]		[[File:AB_GYM4.PNG]]

	=Retsensioonid=		=Retsensioonid=

Ruusjarv: /* Andmebaasi kirjeldus */

2017-05-09T19:40:02Z

Andmebaasi kirjeldus

← Older revision		Revision as of 22:40, 9 May 2017
Line 470:		Line 470:


	[[File:~~AB_GYM2~~.PNG]]		[[File:AB_GYM3.PNG]]

	=Retsensioonid=		=Retsensioonid=