[j.....1]

Hej. Mam problem taki logistyczno algorytmiczny bym to nazwał. Mam wyświetloną listę elementów z kilkoma polami(Id, tytuł, uwagi). Nad nimi dla każdej części jest pole to wpisania czegoś, żeby przefiltrować te dane. Jak rozwiązać ten problem? Przefiltrowanie nastąpi po wpisaniu czegoś w pole i naciśnięciu entera. Więc naciskam enter i tutaj napotykam schodki. Na raz muszę zerknąć na wszystkie wpisane dane w każde z pól i przeszukać te dane i wyświetlić nowe zamiast całej listy. Jeśli pole było puste muszę ominąć jego filtrowanie, gdyż zakłada to dowolność. Więc co ma się dziać po enterze. Filtruj wszystkie po tym polu o ile nie było puste, zapamiętaj dane jakie masz. Nowe dane przefiltruj po kolejnym polu, o ile nie było puste. itp. Dobrze to rozumiem? Czy jest jakaś szybsza/lepsza droga? Używam tutaj observableCollection jako źródło danych. A dane do tej kolekcji wybieram poprzez linq korzystając z entity nałożonego na sqlowe tabele. Dla filtrowanych danych mam stworzoną strukturę, ale okazuje się że nie za bardzo jest tutaj przydatna. No chyba że właśnie to jakoś ze sobą połączyć i zautomatyzować. Ale nie mam za bardzo pomysłu. #programowanie #algorytmy #csharp

[mikkeboss]

@johanneskate1: rownolegly foreach może się nada

[grzgar]

@johanneskate1: hmmm... od strony bazy, to zrobiłbym zmaterializowany widok, który byłby konkatenacją wszystkich pól :D i na nim robił LIKE'a, pytanie jeszcze, ile byłoby tych danych i ile pól - za dużo niewiadomych...

Na tej podstawie bym robił coś po stronie interfejsu - filtrowanie na pewno robiłbym po stronie bazy

a poza tym, to pisz jakoś "ładniej", korzystaj z enter'ów, akapitów itp.

[s.....e]

@grzgar: czy filtrowanie po stronie bazy jest szybsze czy po prostu wygodniejsze?

[grzgar]

@smsrampage: jedno i drugie - latanie po "kontrolce" i sprawdzanie czy tam jest to, czego szukamy jest po prostu bez sensu ;)

Oczywiście zależy to jeszcze od wielu czynników, ale to co możesz zrobić w natywnym środowisku szybciej, wygodniej, zgodnie ze "sztuką"?!, ma same plusy :) a poza tym, nie mieszasz funkcjonalności bazy danych po stronie interfejsu ;)

[j.....1]

@grzgar: czyli sugerujesz, że nie powinienem wysyłać linq przeglądajacego daną tabelę i wypełniać tym obiektów?

[narowerzesamochodem]

@johanneskate1:Dopytam: każdy textblock (czy inny element do filtrowania) odpowiada za filtrowanie po jednym polu, tak?

Jeżeli tak, to imo sprawdzasz, po jakich polach filtrować (czyli które nie są puste), z tego robisz zapytanie Linq do bazy danych, z później wyświetlasz wyniki.

Z ciekawych rzeczy mogę polecić PredicateBuilder, który fajnie rozszerza możliwość budowania złożonych zapytań.

Do tego LinqPad, który pozwala "na sucho" testować zapytania tworzone w Linq.

[grzgar]

@johanneskate1: niestety nie wiem dokładnie czym jest LINQ, bo nie siedzę w tej technologii, ale domyślam się, że jest to jakieś fajne API, dzięki czemu świat jest piękniejszy :)

Napisałem, że zależy wszystko od wielu czynników - to jest jakiś projekt akademicki? czy może projekt w dużej firmie i będzie z tego korzystać wiele osób?

Jeżeli to drugie, to lepiej oddzielić backend (bazę) od frontend'u (UI) i robić filtrowanie "po bożemu",

[j.....1]

@grzgar: na tę chwilę to jest 1 tabela, bez żadnych relacji. Ma kolumny które po prostu przeklejam. Ale muszę te dane do wyświetlenia filtrować w zależności od tego co jest w danej kolumnie. np żeby pole tytuł zawierało litery "sa" obok siebie itp. Nie wiem na ile jest sens tutaj robić to po stronie bazy. Jeśli będzie, a pewnie lada dzień pojawi się coś bardziej zaawansowanego, to skorzystam z sugestii.