Talk:Meeskond:DropDead - Revision history

Rott: /* Prototüübi retsensioon meeskonnalt: Meeskond:Lillelapsed */

2014-12-02T19:32:47Z

Prototüübi retsensioon meeskonnalt: Meeskond:Lillelapsed

← Older revision		Revision as of 22:32, 2 December 2014
Line 18:		Line 18:

	MVVM seisukohast on kõik korras sellega, et vaate code behind'is ei ole üleliigset koodikasutust. Vaate kontekstiks on määratud vastava vaate vaatemudel, kus toimub andmetöötlus. Positiivne aspekt on korrektne bindingute kasutamine xamlis, mis vähendab oluliselt koodikirjutamist code behind'is.		MVVM seisukohast on kõik korras sellega, et vaate code behind'is ei ole üleliigset koodikasutust. Vaate kontekstiks on määratud vastava vaate vaatemudel, kus toimub andmetöötlus. Positiivne aspekt on korrektne bindingute kasutamine xamlis, mis vähendab oluliselt koodikirjutamist code behind'is.

			Koodi ei ole dokumenteeritud ega kommenteeritud.

	Analüüsis välja toodud funktsionaalsusest on realiseeritud väike osa. Realiseeritud vaateid on 1 ning andmebaasi tabeleid on 5 analüüsis väljatoodud 17-st. Kuna kuue vaatemudeli klassi struktuur on täiesti tühi ning realiseeritud on minimaalne osa funktsionaalsusususest, siis tekib küsimus kas projekt saab õigeaegselt teostatuks täies mahus.		Analüüsis välja toodud funktsionaalsusest on realiseeritud väike osa. Realiseeritud vaateid on 1 ning andmebaasi tabeleid on 5 analüüsis väljatoodud 17-st. Kuna kuue vaatemudeli klassi struktuur on täiesti tühi ning realiseeritud on minimaalne osa funktsionaalsusususest, siis tekib küsimus kas projekt saab õigeaegselt teostatuks täies mahus.

Rott: /* Prototüübi retsensioon meeskonnalt: Meeskond:Lillelapsed */

2014-12-02T19:28:25Z

Prototüübi retsensioon meeskonnalt: Meeskond:Lillelapsed

← Older revision		Revision as of 22:28, 2 December 2014
Line 15:		Line 15:
	Kuna puudub äriloogika kiht, siis andmebaasi poole pöördumise meetodid on defineeritud vaatemudelis. Parem lahendus oleks olnud luua eraldi klass, mis hoiaks sama tabeli või siis andmebaasi poole pöörduvaid meetodeid eraldi klassis. See hoiaks erineva funktsioonaalsusega koodi üksteisest eraldatuna ning soodustaks koodi taaskasutatavust.		Kuna puudub äriloogika kiht, siis andmebaasi poole pöördumise meetodid on defineeritud vaatemudelis. Parem lahendus oleks olnud luua eraldi klass, mis hoiaks sama tabeli või siis andmebaasi poole pöörduvaid meetodeid eraldi klassis. See hoiaks erineva funktsioonaalsusega koodi üksteisest eraldatuna ning soodustaks koodi taaskasutatavust.

	Silma jäi objekt tüübiga TEOS BookSearchVm-is, <code> TEOS raamat = (from c in db.TEOS...</code>, mille puhul on häirivaks faktoriks see, et objekti tüübi ~~nimetuses~~ on täielikult suurte tähtedega. Probleemi aitaks lahedanda, kui luua andmebaasi tabelite nimetus vastava formaadiga nagu on C# objekti ~~tüübinimetuse~~ tava. Teise ning sõbralikuma lahendus puhul tuleks määrtleda äriloogika vahekihis endapoolsed domeenimudelid. EF poolt genereeritud mudeliklassid peaksid jääma andmebaasiühenduse vahekihti. Vaatemudel kasutaks vahetult ainult äriloogikakihis defineeritud mudeleid.		Silma jäi objekt tüübiga TEOS BookSearchVm-is, <code> TEOS raamat = (from c in db.TEOS...</code>, mille puhul on häirivaks faktoriks see, et objekti tüübi nimetus on täielikult suurte tähtedega kirjeldatud. Probleemi aitaks lahedanda, kui luua andmebaasi tabelite nimetus vastava formaadiga nagu on selleks C# objekti tüübinimetamise tava. Teise ning sõbralikuma lahendus puhul tuleks määrtleda äriloogika vahekihis endapoolsed domeenimudelid. EF poolt genereeritud mudeliklassid peaksid jääma andmebaasiühenduse vahekihti. Vaatemudel kasutaks vahetult ainult äriloogikakihis defineeritud mudeleid.

	MVVM seisukohast on kõik korras sellega, et vaate code behind'is ei ole üleliigset koodikasutust. Vaate kontekstiks on määratud vastava vaate vaatemudel, kus toimub andmetöötlus. Positiivne aspekt on korrektne bindingute kasutamine xamlis.		MVVM seisukohast on kõik korras sellega, et vaate code behind'is ei ole üleliigset koodikasutust. Vaate kontekstiks on määratud vastava vaate vaatemudel, kus toimub andmetöötlus. Positiivne aspekt on korrektne bindingute kasutamine xamlis, mis vähendab oluliselt koodikirjutamist code behind'is.

	Analüüsis välja toodud funktsionaalsusest on realiseeritud väike osa. ~~Vaateid, mis on realiseeritud~~ on 1 ning andmebaasi tabeleid on 5 analüüsis väljatoodud 17-st. Kuna kuue vaatemudeli klassi struktuur on täiesti tühi ning realiseeritud on minimaalne osa funktsionaalsusususest, siis tekib küsimus kas projekt saab õigeaegselt täies mahus ~~teostatuks~~.		Analüüsis välja toodud funktsionaalsusest on realiseeritud väike osa. Realiseeritud vaateid on 1 ning andmebaasi tabeleid on 5 analüüsis väljatoodud 17-st. Kuna kuue vaatemudeli klassi struktuur on täiesti tühi ning realiseeritud on minimaalne osa funktsionaalsusususest, siis tekib küsimus kas projekt saab õigeaegselt teostatuks täies mahus.

Rott: Created page with "==Prototüübi retsensioon meeskonnalt: Meeskond:Lillelapsed== Prototüübi paigaldamine ning kävitamine toimus sujuvalt vastavalt koostatud juhendile ning sellega probleem…"

2014-12-02T19:24:55Z

Created page with "==Prototüübi retsensioon meeskonnalt: Meeskond:Lillelapsed== Prototüübi paigaldamine ning kävitamine toimus sujuvalt vastavalt koostatud juhendile ning sellega probleem…"

New page

==Prototüübi retsensioon meeskonnalt: [[Meeskond:Lillelapsed]]==

Prototüübi paigaldamine ning kävitamine toimus sujuvalt vastavalt koostatud juhendile ning sellega probleeme ei esineud.
Projekti lahenduse üldine struktuur ning ülesehitus on natukene segane. Projekti lahendus on jagatud neljaks alamprojektiks:
* BookKeeper.ConsoleTest
* BookKeeper.Models
* BookKeerper.ViewModels
* BookKeerper.Views
Alamprojektid ei ole jagatund järgnevalt mainitud kihtidesse nii nagu õppeaine praktikumis soovitati.
* Data Access Layer (Andmebaasiühendus)
* Business Logic Layer (Äriloogika)
* Presentation Layer (WPF)
Selle asemel on alamprojektide näol realiseeritud WPF-i MVVM arhitektuuri muster. Pigem tuleks realiseerida MVVM muster ühes alamprojektis, milleks võiks olla presentatsioonikiht ning eraldada vaated ning vaatemudelid erinevatesse folderitesse või nimeruumidesse.

Kuna puudub äriloogika kiht, siis andmebaasi poole pöördumise meetodid on defineeritud vaatemudelis. Parem lahendus oleks olnud luua eraldi klass, mis hoiaks sama tabeli või siis andmebaasi poole pöörduvaid meetodeid eraldi klassis. See hoiaks erineva funktsioonaalsusega koodi üksteisest eraldatuna ning soodustaks koodi taaskasutatavust.

Silma jäi objekt tüübiga TEOS BookSearchVm-is, <code> TEOS raamat = (from c in db.TEOS...</code>, mille puhul on häirivaks faktoriks see, et objekti tüübi nimetuses on täielikult suurte tähtedega. Probleemi aitaks lahedanda, kui luua andmebaasi tabelite nimetus vastava formaadiga nagu on C# objekti tüübinimetuse tava. Teise ning sõbralikuma lahendus puhul tuleks määrtleda äriloogika vahekihis endapoolsed domeenimudelid. EF poolt genereeritud mudeliklassid peaksid jääma andmebaasiühenduse vahekihti. Vaatemudel kasutaks vahetult ainult äriloogikakihis defineeritud mudeleid.

MVVM seisukohast on kõik korras sellega, et vaate code behind'is ei ole üleliigset koodikasutust. Vaate kontekstiks on määratud vastava vaate vaatemudel, kus toimub andmetöötlus. Positiivne aspekt on korrektne bindingute kasutamine xamlis.

Analüüsis välja toodud funktsionaalsusest on realiseeritud väike osa. Vaateid, mis on realiseeritud on 1 ning andmebaasi tabeleid on 5 analüüsis väljatoodud 17-st. Kuna kuue vaatemudeli klassi struktuur on täiesti tühi ning realiseeritud on minimaalne osa funktsionaalsusususest, siis tekib küsimus kas projekt saab õigeaegselt täies mahus teostatuks.