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. 
Egy ilyen attribútummal mennyi vagy független az adatbázistól?
[Table]
public class TimeTableItem : ObservableObject
{ /* ... */ }
Kicsit furcsán fest.
[ Szerkesztve ]
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 ]
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.
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 ]
Persze, simán jó lehet az IQueryable<T>.
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 ]
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 
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]
Now with 100% more GitHub! Kicsit kényelmesebb mindenkinek, mint a zip fájlt tologatni 
Itt is szeretném megköszönni a részletes magyarázatot
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.
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...
Hja, a linkről nálam is... Átmásoltam pastebinre: [link]
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
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.
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 ]
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.
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.
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.
A te elképzelésedről nekem inkább a távolsági közlekedés jut eszembe, de a városi közlekedéssel kapcsolatban lehet, hogy felesleges ilyen szűrést beépíteni (már csak az utak két oldalán elhelyezkedő megállók miatt sem). Az alkalmazást pedig városi közlekedéshez tervezném, legalábbis az adatbázist már ahhoz vittem fel, így ezen nem szívesen változtatnék, ~9000 soros jelenleg az adatbázis.
Az sqlmetal-al legenerált datacontextet szoktál használni?
Ja, én egész eddig azt hittem, hogy távolsági menetrend lesz, ahhoz készültem
SqlMetalt sose használtam, EF-et is csak Code Firsttel.
De ha már kézzel írod a DB-t, az "avasrol" milyen entitás? 
[ Szerkesztve ]
Az a tábla tartalmazza a konkrét indulási időket, illetve az indulási időhöz tartozó járat azonosítóját.
Az első pár elképzelés a táblákat illetően még más volt, aztán később már túl sok adatot tartalmazott, így maradt ez.
SQL CE db
Első körben csak egy járatot tartalmazott a tábla, amely Miskolc kis városának egyik nevezetes területéről, az Avas-ról indul, pontosabban az avasi kilátótól, így a tábla neve az adatbázissal kapcsolatos első próbálkozásokból maradt meg, mivel az egyéb próbálkozásokkal nem barátkozott meg az sql compact, így végül inkább nem zargattam. 
Végre ismét jutott időm erre az "apró" problémára, legalábbis a megoldás keresésére.
Az sqlmetal ezt a fájlt generálja, azonban a te példádhoz képest "kissé" problémásabb megérteni, mi micsoda
Ezzel esetleg tudok tovább haladni, vagy próbáljak egy új class segítségével elérést biztosítani az adatbázishoz?
