Talk:Meeskond:DropDead: Difference between revisions
Created page with "==Prototüübi retsensioon meeskonnalt: Meeskond:Lillelapsed== Prototüübi paigaldamine ning kävitamine toimus sujuvalt vastavalt koostatud juhendile ning sellega probleem…" |
|||
| 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 | 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. | 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. | ||
Revision as of 21:28, 2 December 2014
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, TEOS raamat = (from c in db.TEOS..., 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, mis vähendab oluliselt koodikirjutamist code behind'is.
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.
