[Re:] [Karma:] Windows Phone fejlesztés: MVVM és adatbázis példakód - BLOGOUT fórum

üzenetek

hozzászólások


Peter Kiss
(senior tag)
Blog

Az IEnumerable<T> messze nem a legjobb interface az adatkapcsolathoz, mivel valahányszor hozzányúlsz, lehúzza az egész adattáblát memóriába. :U

Egy ilyen attribútummal mennyi vagy független az adatbázistól?

[Table]
public class TimeTableItem : ObservableObject
{ /* ... */ }

Kicsit furcsán fest.

[ Szerkesztve ]


Karma
(félisten)
Blog

Attól, hogy attribútum van rajta, még mindig egy POCO-ról van szó, szerintem ez elég független az adatbázistól. Na jó, az ID és a Version mezők tényleg rontanak rajta, de szerintem nem vészes.

Javaban használtál már JAXB-t, Springet vagy Camelt? Ott is elég gyakori, hogy annotációkkal tolnak meg POJO-kat, hogy ne kelljen feleslegesen duplikálni dolgokat.

Tudtommal az lenne a lényege az IEnumerable-nek, hogy addig nem végez semmilyen műveletet, amíg nem akarja valaki kiértékelni, márpedig azt csak a ListBox fogja megtenni property change-enként egyszer, meg induláskor. Az induláskor teljes felnyalás a példa egyszerűsége miatt ilyen (lehetne limitálni meg stb), szűréskor meg a LINQ to SQL már berakja a WHERE feltételt magától. Tévednék?

[ Szerkesztve ]


Peter Kiss
(senior tag)
Blog

Tévedsz. Az IEnumerable<T> extension-ök Func<>-torokkal operál, ezekben tud a rendszer pl. SQL kódot generálni, mivel nem lát bele. Az IQueryable<T> extension method-jai használnak Expression<Func<>> típusú paramétereket, ezekbe lát bele a rendszer. Ennél fogva egy Where() hívás a te megoldásoddal azt eredményezné, hogy a szűrés a memóriában valósul meg, nem pedig pl. az SQL szerveren (és nem csak a limitált adathalmaz jön vissza).

És önmagában az IEnumerable<T> semmi köze a deferred executing-hoz.


Karma
(félisten)
Blog

Hupsz. Akkor itt tényleg képzavarban voltam, mert igazából mindig csak objektumokra használom a LINQ-t és láttam hogy később értékeli ki a dolgokat az IEnumerable...

Odáig oké, hogy rossz amit írtam, de mit javasolnál helyette akkor? IQueryable interfészt kiajánlani helyette esetleg? Nem hiszem, hogy az absztrakciós igényem ördögtől való azért.

[ Szerkesztve ]


Peter Kiss
(senior tag)
Blog

Persze, simán jó lehet az IQueryable<T>.


Karma
(félisten)
Blog

Köszi, majd átírom és cserélem a szöveget is meg a kódot is.

Valami más észrevételed van még esetleg? Szeretek tanulni a hibáimból :)

[ Szerkesztve ]


Karma
(félisten)
Blog

Megcsináltam a módosításokat, de előtte tettem be egy loggert a DataContextnek, így szépen látszik hogy pontosan úgy van ahogy leírtad :R

Az eredeti formában, ahogy feltöltöttem, a minden szűrés a memóriában történt, a DB-ből teljes felolvasásokat végzett. Ez a sor ismétlődik a logban minden DB műveletnél:

SELECT [t0].[_version], [t0].[Id], [t0].[FromStop], [t0].[ToStop], [t0].[StartTime], [t0].[EndTime]
FROM [TimeTableItem] AS [t0]

Miután kidobtam az AsEnumerable hívást, mindjárt normalizálódott.

Ez lett a városnevek gyűjtéséből:

SELECT [t3].[FromStop]
FROM (
SELECT [t2].[FromStop]
FROM (
SELECT [t0].[FromStop]
FROM [TimeTableItem] AS [t0]
UNION
SELECT [t1].[ToStop]
FROM [TimeTableItem] AS [t1]
) AS [t2]
) AS [t3]
ORDER BY [t3].[FromStop]

És ez a városra szűrésből:

SELECT [t0].[_version], [t0].[Id], [t0].[FromStop], [t0].[ToStop], [t0].[StartTime], [t0].[EndTime]
FROM [TimeTableItem] AS [t0]
WHERE ([t0].[FromStop] = @p0) OR ([t0].[ToStop] = @p1)
-- @p0: Input String (Size = 9; Prec = 0; Scale = 0) [Kecskemét]
-- @p1: Input String (Size = 9; Prec = 0; Scale = 0) [Kecskemét]


Karma
(félisten)
Blog

Now with 100% more GitHub! Kicsit kényelmesebb mindenkinek, mint a zip fájlt tologatni :P


Peter Kiss
(senior tag)
Blog

Megnyugodtam. :DDD


Pttypang
(veterán)
Blog

Itt is szeretném megköszönni a részletes magyarázatot :R


Pttypang
(veterán)
Blog

Az MVVM 3-ban nincs benne az ObservableObject? o.O


Karma
(félisten)
Blog

Az MVVMLight 3 elég régen volt, azt ne erőltesd. A Google alapján úgy tűnik, hogy egy évvel később írták meg az osztályt.

Viszont mivel nem egy nagy dologról van szó, innen át tudod emelni a forrását.


Pttypang
(veterán)
Blog

We encountered a problem loading "GalaSoft.MvvmLight/GalaSoft.MvvmLight%20%28NET35%29/ObservableObject.cs". If you continuously encounter this issue, please contact us.
:(
Nem az otthoni gépen vagyok, erről pedig nem tudom megoldani a gyors keresést...


Karma
(félisten)
Blog

Hja, a linkről nálam is... Átmásoltam pastebinre: [link]


Pttypang
(veterán)
Blog

Végre tudtam ismét foglalkozni a projekttel, így lenne is pár kérdésem.
1, A listpicker nélkül megoldható a dolog, vagy akkor már érdemesebb több oldalban gondolkodnom?
2, A TimeTableDataContext-ben nem találja a TimeTableItem meghatározásokat :( (StartTime, FromStop, etc.) Mit hagyhattam ki? o.O [link]

A továbbiakat addig inkább nem is próbálom, amíg ezeket nem értem meg, mert esetleg hibás elképzelés alapján próbálnám meg felépíteni a programot :(


Karma
(félisten)
Blog

1) A ListPickert csak azért tettem be, hogy legyen valami amit csinál az app dinamikusan. Ha elmondod hogy mit szeretnél elérni (akár privátban, ha olyan), mondhatok rá alternatívát.

2) A TimeTableItemet tartalmazó TimeTableItem.cs fájlt le tudnád screenshotolni? Pl. lehet, hogy elírtad a hozzáférési szintjét ezeknek a propertyknek, és private lett.


Pttypang
(veterán)
Blog

Az alap elképzelésem a teljes lista, amiből kiválaszt a user egy járatot, ekkor átnavigálja egy másik lapra, ahol a járathoz tartozó lekérdezés futna le, esetleg még extraként egy gomb kinavigálna egy másik lapra, ahol a járathoz tartozó megállóka lennének kilistázva, miután választott onnan a user, visszatér az előző lapra, ahol frissíti a kilistázott indulási időket, immáron hozzáadva a kiválasztott megállóhoz tartozó menetidővel.
Ez lett volna a favágós sql query-s substringes katyvaszból, de a bindingos megoldással valószínűleg sokkal egyszerűbben megoldható a dolog, kevesebb lappal :)
Csak a listboxos verziók lettek volna megfelelőbbek a selecteditem miatt, legalábbis eddig főleg ebben gondolkodtam.

[link]
Az általam nem használt oszlopokat töröltem, de a meglévőket is hiányolja o.O

[ Szerkesztve ]


Karma
(félisten)
Blog

Classon belül van még egy class. A felsőt (ami a namespace után kezdődik) töröld ki!

Az appra majd még írok valamit hamarosan.


Karma
(félisten)
Blog

Ebben az elképzelésben nekem az sántít, hogy ha sok járat van (miért ne lenne?), a felhasználónak somat kell görgetnie mire célba ér, és az elég frusztráló. Meg mi van, ha kínkeservesen lejut Zalaborzasztóig, aztán kiderül, hogy nincs is járat Mucsaröcsögére? Instant ragequit.

Én különvenném a honnan-hova kiválasztást külön oldalakra; vagy még inkább egy Pivotra. Az első oldala egy városlista (a névjegyzékhez hasonló ugrási és keresési lehetőséggel, + egy gombnyomással az aktuális helyzet alapján kiválasztással), a második már a járatlista amik az adott helyről indulnak, a harmadikon meg jöhetnek az idők és egyéb történetek.


Karma
(félisten)
Blog

A data binding és a LINQ abban segít, hogy ugyanazt a kódot, amit kézzel hosszasan és redundánsan megírnál, deklaratívan kérd a frameworktől és kész. A UI adatkezelés esetében egyértelmű az előnye, de az SQL esetében se marad el. Minél kevesebb kódot írsz, annál kevesebbet kell karbantartani. :)

De ettől még ugyanannyi műveletet kell kitalálnod.

üzenetek