"Cykl zycia strony" a ladowanie danych z bazy danych;

Witam;

Zaczela mnie nurtowac kwestia ladowania danych z baz danych. Mam taki kod:

" OleDbConnection con = new OleDbConnection();
con.ConnectionString = "provider=microsoft.jet.oledb.4.0; data source=jakas baza danych.db";
con.Open();

    DataSet ds = new DataSet();
    OleDbDataAdapter da = new OleDbDataAdapter();
    da = new OleDbDataAdapter("Select * From Produkty ORDER By Punkty DESC", con);
    da.Fill(ds);
    Repeater.DataSource = ds;
    Repeater.DataBind();
    con.Close();

"

W ktorym miejscu "bezpieczniej" jest umiescic taki kod ?. W Page_Load, czy moze jednak w Page_Preload ?. Chce miec pewnosc, ze strona nim wyswietli wszystko zdazy pobrac potrzebne informacje z bazdy danych.

Dzieki za odpowiedz !

Ja bym taki kod wywoływał raczej w Page_Load. Tylko takiego kodu oczywiście nie powinno być w code behind strony...

A dlaczego "nie powinno" ?. To w takim razie w ktorym miejscu, jak nie w "code behind " ?. Zaintrygowales mnie teraz..
Edit: ok, juz wiem, od czegos w koncu jest web.config, zakrecilem sie ;)

shagohad napisał(a):

A dlaczego "nie powinno" ?. To w takim razie w ktorym miejscu, jak nie w "code behind " ?. Zaintrygowales mnie teraz..

Code behind strony to miejsce na logikę widoku, nie logikę aplikacji czy dostępu do danych.
Odpytywanie bazy powinno odbywać się w jakiejś klasie z warstwy DAO, wołanej przez jakiś prezenter z którym dana strona jest powiązana.
Inna rzecz, że ręczne pisanie zapytań to okradanie samego siebie z czasu.

Edit: ok, juz wiem, od czegos w koncu jest web.config, zakrecilem sie ;)

No jest, od konfiguracji. Tylko nie wiem, co to ma do tego wątku.

Mam rozumiec, ze chodzilo Tobie o to: http://pl.wikipedia.org/wiki/ADO.NET ?. Szczerze mowiac, pierwszy raz o tym slysze i bede musial sie zaglebic w temat. Aczkolwiek nie wiem, co zlego jest w tworzeniu zapytan w code behind, skoro i tak dziala tak, jak powinno. Z tym web.config chodzilo mi o to, ze tam mozna po prostu zdefiniowac connection string, do ktorego moge sie odwolywac z kazdej klasy.

Z ADO.NET to Ty korzystasz akurat tworząc obiekty Connection i DataAdapter. Mi chodziło o ORM - Entity Framework, NHibernate, itp. Czyli narzędzia, które kod SQL generują same.

shagohad napisał(a):

Aczkolwiek nie wiem, co zlego jest w tworzeniu zapytan w code behind, skoro i tak dziala tak, jak powinno.

Łamiesz w ten sposób SRP: http://pl.wikipedia.org/wiki/Zasada_jednej_odpowiedzialno%C5%9Bci i piszesz kod, którego się nie da testować. Robienie czegoś takiego nie ma nic wspólnego z programowaniem, to zwykła fuszerka.

Z tym web.config chodzilo mi o to, ze tam mozna po prostu zdefiniowac connection string, do ktorego moge sie odwolywac z kazdej klasy.

No tak, to jasne, że connection string siedzi w configu.

shagohad napisał(a):

Aczkolwiek nie wiem, co zlego jest w tworzeniu zapytan w code behind, skoro i tak dziala tak, jak powinno.

Kod napisany w Brainfucku też działa jak powinien, a jednak ja wolę w nim nie pisać.

@somekind dobrze prawi. Aplikacja powinna mieć budowę warstwową. Co najmniej trzy:

• warstwa dostępu do danych (zapytania do bazy)
• warstwa przetwarzająca dane (logika aplikacji, wykonywanie operacji)
• warstwa wyświetlania (interfejs użytkownika)

U ciebie aplikacja składa się tylko z tej ostatniej. Dlaczego chcesz mieć przynajmniej warstwę dostępu do danych (poza argumentami wyżej)? A co jak będziesz chciał to samo zapytanie wykonać na innej stronie (pomijam kwestię ORM)? Przekleisz je? Ok, nadal będzie działać. Potem jednak nadejdzie konieczność zmiany w strukturze bazy. Wtedy będziesz musiał szukać po całym kodzie swoich zapytań. Prawdopodobieństwo popełnienia błędu jest wtedy duże.

Ok, do tej pory nie bylem swiadom o istnieniu czegos takiego, wiec dziekuje za przedstawienie mi tego. Od teraz bede to mial na uwadze i bede sie po prostu wglebial w temat i poszerzal swoja wiedze w tym zakresie, zeby nie odstawiac "fuszerki".