asp.net tworzyc obiekty czy nie

Witam,
Mam takie trzy pytania:

1. Przy tworzeniu aplikacji internetowej w asp.net, która ma połączenie z bazą danych. załóżmy, że jest to np baza klientów. To w momencie kiedy ktoś wpisuje do formularza nowego klienta, to dodawać to do bazy danych, a oprócz tego stworzyć sobie klasę klient i tworzyć obiekt tej klasy, czy tylko wpisywać do bazy danych? będzie tam kilka rzeczy, które później będę musiała wykonywać różne działania, więc chyba wygodniej będzie stworzyć też obiekty?
2. Czy ktoś może mi tak prosto wytłumaczyć czy powinnam używać kontrolek np.button z html czy takiego standardowego?
3. Jak już pytam, to od razu tutaj spytam jeśli jako klienta mogę mieć albo firmę albo osobę prywatną to lepiej rozdzielić to sobie w bazie danych na różne tabele, czy lepiej jak zrobię dwa formularze w zależności od wybranej opcji i wpisywać tylko wybrane atrybuty do bazy danych do tabeli klient?
   Z góry dziękuję za wszystkie odpowiedzi! :)

Najpierw musisz napisać czy używasz WebForms czy MVC
Co do obiektu to gdzie go będziesz przechowywać w momencie przeładowywania strony ?

Obrazowo button ASP wykonuje się po stronie serwera (c#), a HTML po stronie przeglądarki (JS). Do zapisu danych do bazy raczej używa się ASP choćby dokonując zapisu za pomocą LINQ natomiast HTML bardziej nadaje się np. do otwarcia okienka ZOOM w polu edycyjnym

Sylwia1992 napisał(a):

1. Przy tworzeniu aplikacji internetowej w asp.net, która ma połączenie z bazą danych. załóżmy, że jest to np baza klientów. To w momencie kiedy ktoś wpisuje do formularza nowego klienta, to dodawać to do bazy danych, a oprócz tego stworzyć sobie klasę klient i tworzyć obiekt tej klasy, czy tylko wpisywać do bazy danych? będzie tam kilka rzeczy, które później będę musiała wykonywać różne działania, więc chyba wygodniej będzie stworzyć też obiekty?

Trudno powiedziec. Przydaloby sie troche wiecej konkretow :)

Sylwia1992 napisał(a):

2. Czy ktoś może mi tak prosto wytłumaczyć czy powinnam używać kontrolek np.button z html czy takiego standardowego?

Dla mnie standardowym buttonem jest ten z HTMLa :)

Srednio znam ASP.NET ale z tego co mi wiadomo button ASP.NET jest widoczny w kodzie dzielajacym po stronie serwera, co ma ten plus ze zapewne latwiej go obslugiwac - mozesz sobie podpiac pod niego zdarzenia klikniecia, odczytac jego parametry w naturalny dla tej platformy sposób itd. Wydaje mi sie, że ze zwyklym buttonem HTML takich rzeczy nie zrobisz ale tak jak pisalem wyzej specem od ASP.NET nie jestem.

Sylwia1992 napisał(a):

3. Jak już pytam, to od razu tutaj spytam jeśli jako klienta mogę mieć albo firmę albo osobę prywatną to lepiej rozdzielić to sobie w bazie danych na różne tabele, czy lepiej jak zrobię dwa formularze w zależności od wybranej opcji i wpisywać tylko wybrane atrybuty do bazy danych do tabeli klient?
   Z góry dziękuję za wszystkie odpowiedzi! :)

Jeżeli potrzebujesz tylko rozróżnić czy klient jest osobą prywatną czy firmą to nie ma za bardzo sensu dzielić to na dodatkowe tabele. No chyba, ze z jakis wzgledow optymalizacyjnych mialoby to sens.

Co innego jezeli oprocz tego rozroznienia pojawia sie jakies dodatkowe informacje - np numer REGON czy liczba pracowników w przypadku firmy. Wtedy już można myśleć o kilku tabelach, niekoniecznie dwoch (mozna utworzyc np. trzy tabele: klienci, klienci_osoby_prywatne, klienci_firmy - w pierwszej tabeli bylyby pola ktore sa wlasciwe dla obu typow klientow)

cw napisał(a):

Najpierw musisz napisać czy używasz WebForms czy MVC
Co do obiektu to gdzie go będziesz przechowywać w momencie przeładowywania strony ?

Używam WebForms. Szczerze mówiąc nie mam pojęcia jak to powinno wtedy działać, pierwszy raz robię aplikację internetową, wcześniej robiłam tylko takie zwykłe windowsowe aplikacje.

Trudno powiedziec. Przydaloby sie troche wiecej konkretow :)

Ma to być aplikacja do liczenia mediów, ogólnych kosztów razem z czynszem i generalnie do zarządzania najmem. Ale właśnie np. do obliczania różnych opłat będę musiała przekształcać w różny sposób dane z odczytów liczników i jakieś stałe przypisane do najemców i właśnie przy takich obliczeniach byłoby się pewnie prościej odwoływać do obiektów.

Jeżeli potrzebujesz tylko rozróżnić czy klient jest osobą prywatną czy firmą to nie ma za bardzo sensu dzielić to na dodatkowe tabele. No chyba, ze z jakis wzgledow optymalizacyjnych mialoby to sens.

Co innego jezeli oprocz tego rozroznienia pojawia sie jakies dodatkowe informacje - np numer REGON czy liczba pracowników w przypadku firmy. Wtedy już można myśleć o kilku tabelach, niekoniecznie dwoch (mozna utworzyc np. trzy tabele: klienci, klienci_osoby_prywatne, klienci_firmy - w pierwszej tabeli bylyby pola ktore sa wlasciwe dla obu typow klientow)

</quote> pojawiają się osobne pola dla jednego i dla drugiego, właśnie np. ten regon . i myślałam właśnie nad trzema tabelami, tylko nie bardzo wiem jakie zrobić relacje między nimi. A co myślicie o tej opcji z jedną tabelą i wpisywaniu wybranych danych tylko? Bo w formularzu bym zrobiła rozróżnienie i wpisywałoby się inne dane dla firmy a inne dla osoby prywatnej, a później można by to rodzielać po prostu za pomocą zapytania sql?

Sylwia1992 napisał(a):

Ma to być aplikacja do liczenia mediów, ogólnych kosztów razem z czynszem i generalnie do zarządzania najmem. Ale właśnie np. do obliczania różnych opłat będę musiała przekształcać w różny sposób dane z odczytów liczników i jakieś stałe przypisane do najemców i właśnie przy takich obliczeniach byłoby się pewnie prościej odwoływać do obiektów.

A mozna wiedziec jak Ty wlasciwie wymieniasz informacje z baza danych? Jakiej technologii uzywasz? Bo jezeli korzystasz z jakiegos systemu ORM to pewnie masz cos takiego jak klasy encji - taka klasa, ktora odzwierciedla tabele w bazie danych. Nie wiem jak akurat jest w .NET ale w takiej sytuacji byc moze da sie pola takiej encji przypisac do formularza, tak aby po wypelnieniu formularza automatycznie zostala utworzona klasa encji - nie wiem czy dobrze to wytlumaczylem.

Niestety jezeli chodzi o .NET to kieruje sie tu bardziej intuicja i nie wiem na ile jestem Ci w stanie pomoc.

Sylwia1992 napisał(a):

pojawiają się osobne pola dla jednego i dla drugiego, właśnie np. ten regon . i myślałam właśnie nad trzema tabelami, tylko nie bardzo wiem jakie zrobić relacje między nimi.

A mozna wiedziec z czym konkretnie masz problem? Bo wystarczy utworzyc sobie klucz podstawowy w tabeli klienci oraz klucze obce w innych tabelach. Nie jest to jakies specjalnie skomplikowane. O ile dobrze pamietam to Visual Studio udostepnia nawet jakies narzedzia do projektowania baz danych i mozna te tabele wlasciwie narysowac i polaczyc strzalkami :)

No chyba, ze korzystasz z jakiegos ORMa i nie wiesz jak prawidlowo napisac klasy Encji, ktore sa powiazane z innymi encjami?

Sylwia1992 napisał(a):

A co myślicie o tej opcji z jedną tabelą i wpisywaniu wybranych danych tylko? Bo w formularzu bym zrobiła rozróżnienie i wpisywałoby się inne dane dla firmy a inne dla osoby prywatnej, a później można by to rodzielać po prostu za pomocą zapytania sql?

Rozwiazanie takie sobie. Problem polega na tym, ze jak masz np. 90% prywatnych klientow to dosc duzo danych bedzie NULLami. Wyobraz sobie teraz, ze dojdzie Ci kolejny typ klienta i niech ten typ bedzie dosc specyficzny - na tyle specyficzny ze na 10 000 klientow jest ich "az dwoch". Z powodu tych dwoch klientow bedziesz rozszerzac tabele o kilka dodatkowych kolumn? A jak specyficznych klientow bedzie kilka? Znowu nowe kolumny?

Na tym etapie proponuję:

• zapomnij o WinForms'ach. Zakoduj sobie w głowie, że w ASP.NET najważniejszym słowem jest STATELESS, strony WWW nie przechowują swoich stanów, jak strona się przeładuje tracisz swoje zmienne. Najprościej będzie przechowywać je w obiekcie SESSION
• używaj tylko kontrolek ASP. Są "natywne" dla .NETa i bardzo łatwe do obsługi.
• poczytaj o LINQ. Możesz za jego pomocą bardzo prosto dodawać, edytować, usuwać i wyszukiwać rekordy w bazie
• jako bazy danych użyj MSSQL (może być w wersji EXPORESS) jest on "natywny" dla ASP.NET
• staraj się jak najwięcej operacji typu "przeliczanie danych" wykonywać bezpośrednio w bazie danych za pomocą procedur przechowywanych, a do prezentacji danych używając widoków.

Niestety pisanie programów za pomocą ASP.NET to konieczność równoczesnego korzystania z wielu technologii

Co do oddzielnych tabel na klientów indywidualnych i firmy osobiście jestem przeciwnikiem takiego rozwiązania. Staram się aby w bazie było jak najmniej tabel, ale jest to sprawa bardzo indywidualna.

Sylwia1992 napisał(a):

Używam WebForms. Szczerze mówiąc nie mam pojęcia jak to powinno wtedy działać, pierwszy raz robię aplikację internetową, wcześniej robiłam tylko takie zwykłe windowsowe aplikacje.

I w tych windowsowych aplikacjach nie używałaś obiektów? I może jeszcze pisałaś je w C#?

Sylwia1992 napisał(a):

i myślałam właśnie nad trzema tabelami, tylko nie bardzo wiem jakie zrobić relacje między nimi. A co myślicie o tej opcji z jedną tabelą i wpisywaniu wybranych danych tylko? Bo w formularzu bym zrobiła rozróżnienie i wpisywałoby się inne dane dla firmy a inne dla osoby prywatnej, a później można by to rodzielać po prostu za pomocą zapytania sql?

Nie robi się relacji między tabelami, bo tabele i relacja to synonimy. Między tabelami możesz mieć powiązania realizowane za pomocą kluczy obcych.

Generalnie są trzy podejścia (nomenklatura z programowania obiektowego przy założeniu, że istnieje bazowa klasa Klient i dziedziczące z niej KlientPrywatny i KlientFirma:

1. table per hierarchy - jedna tabela dla wszystkich klas, wartości w polach niewłaściwych dla danej klasy wypełniane są nullami;
2. table per type - jedna tabela dla właściwości z klasy bazowej + dodatkowe tabele dla każdej klasy dziedziczącej, wszystkie mają ten sam klucz główny;
3. table per concrete class - każda klasa ma swoją oddzielną tabelę

Każde z tych podejść możesz zastosować oczywiście nie używając klas. Tylko po co?

Ogólnie zainteresuj się tematem ORM oraz Entity Framework, i nie pisz SQL ręcznie.

cw napisał(a):

Na tym etapie proponuję:

• zapomnij o WinForms'ach. Zakoduj sobie w głowie, że w ASP.NET najważniejszym słowem jest STATELESS, strony WWW nie przechowują swoich stanów, jak strona się przeładuje tracisz swoje zmienne. Najprościej będzie przechowywać je w obiekcie SESSION

To HTTP jest stateless. Wiele technologi webowych jest stateless. Ale WebFormsy nie są, nie mąć jej w głowie.

• używaj tylko kontrolek ASP. Są "natywne" dla .NETa i bardzo łatwe do obsługi.

Kontrolek serwerowych używa się tam, gdzie wykonuje się coś po stronie serwera. Po stronie klienta używa się standardowych kontrolek HTML.

• poczytaj o LINQ. Możesz za jego pomocą bardzo prosto dodawać, edytować, usuwać i wyszukiwać rekordy w bazie

I to wszystko, co można za jego pomocą zrobić. Nie zrobi się chyba nawet mapowania n:n ani dziedziczenia.

• staraj się jak najwięcej operacji typu "przeliczanie danych" wykonywać bezpośrednio w bazie danych za pomocą procedur przechowywanych, a do prezentacji danych używając widoków.

To po co polecasz ORM, skoro ma go nie używać?

"To HTTP jest stateless. Wiele technologi webowych jest stateless. Ale WebFormsy nie są, nie mąć jej w głowie." - tak, ale jest to osiągane za pomocą dodatkowych rozwiązań (często zresztą krytykowanych za dużą ilość przesyłanych danych) i jeżeli na początku programowania w asp.net próbuje się przeniesie pewne nawyki z WinFormsów to można się bardzo zdziwić. Dlatego zwróciłem na to uwagę. Co do programowania bezpośrednio baz danych, zawsze będzie to wydajniejsze niż przetwarzanie z poziomu swego kodu. Oczywiście są różne szkoły, ale ja preferuję właśnie taką.

Co do programowania bezpośrednio baz danych, zawsze będzie to wydajniejsze niż przetwarzanie z poziomu swego kodu. Oczywiście są różne szkoły, ale ja preferuję właśnie taką.

W sensie preferujesz niezarzadzalny i nietestowalny kod po stronie bazy pozamykany w procedurach niz 1 zapytanie w C#, ktore da sie testowac? Przeciez to jakas farsa. Dopoki profiler nie pokaze, ze trzeba w ogole myslec o czyms takim jak baza, to sie tego nie robi. Szkoda czasu, pieniedzy i nerwow.

cw napisał(a):

"To HTTP jest stateless. Wiele technologi webowych jest stateless. Ale WebFormsy nie są, nie mąć jej w głowie." - tak, ale jest to osiągane za pomocą dodatkowych rozwiązań (często zresztą krytykowanych za dużą ilość przesyłanych danych)

To nie są rozwiązania dodatkowe, lecz domyślne i preferowane.

jeżeli na początku programowania w asp.net próbuje się przeniesie pewne nawyki z WinFormsów to można się bardzo zdziwić.

Zdziwić? WebFormsy powstały po to, aby programować webowo tak, jak na desktopie, stąd designer, kontrolki, zdarzenia i stanowość.

Dziwna to jest Twoja propozycja. Da się pisać bezstanowe aplikacje w WebFormsach, ale po co? Lepiej już użyć innej technologii.

Co do programowania bezpośrednio baz danych, zawsze będzie to wydajniejsze niż przetwarzanie z poziomu swego kodu. Oczywiście są różne szkoły, ale ja preferuję właśnie taką.

Zatem udowodnij, że select albo insert wykonywany po stronie bazy danych jest wydajniejszy od takiego wysłanego z aplikacji.

Po stronie bazy danych sens ma przetwarzanie wsadowe, albo generowanie raportów bazujących na wielu tabelach, ale nie wszystkie CRUDy czy inne proste operacje.

Jakoś nie zauważyłem, aby z baz danych wycofywano takie rozwiązania jak procedury przechowywane, widoki, a sam język SQL też ma się dobrze. Wszelakiego rodzaju ORM są zawsze warstwą pośrednią i siłą rzeczy nie zapewnią takiej wydajności jak zapytania SQL wykonywane bezpośrednio w bazie. Co do testów jednostkowych to nie róbmy z nich jakiejś religii (pomijam już fakt, że mówimy o WebFormsach, a nie o MVC). Bazy danych i oprogramowanie je obsługujące tworzy się od dziesięcioleci i jakoś działało nawet jak nie było testów jednostkowych wg obowiązującej dzisiaj definicji. Poza tym czy wybrać code first /model first / database first to jest sprawa zależna od wielu czynników i wskazywanie tylko jednego rozwiązanie jako poprawnego jest trochę śmieszne.

"Zdziwić? WebFormsy powstały po to, aby programować webowo tak, jak na desktopie, stąd designer, kontrolki, zdarzenia i stanowość." -to zrób prosty MessagBox otwierany z "formularza głównego" w którym wyświetli się lista będąca wynikiem zapytania z parametrem przekazanym z z tego formularza, a następnie zwróć wynik wyboru użytkownika do pola TextBox "formularza głównego" i porównaj nakład pracy.

"Zatem udowodnij, że select albo insert wykonywany" - kilka miesięcy temu w swojej aplikacji zrezygnowałem własnie z wyszukiwania realizowanego bezpośrednio w kodzie programu i przeniosłem je do procedury przechowywanej. Procedura wyszła najdłuższa jaką w życiu napisałem, ale szybkość wyszukiwania spadła z minut na sekundy.

..... porównaj nakład pracy w WinForms i WebForms

cw napisał(a):

Jakoś nie zauważyłem, aby z baz danych wycofywano takie rozwiązania jak procedury przechowywane, widoki, a sam język SQL też ma się dobrze.

Ja nie mówię, że procedury czy widoki są złe. Ja twierdzę, że nie ma sensu ich pisać w przypadku prostych operacji CRUD.

Wszelakiego rodzaju ORM są zawsze warstwą pośrednią i siłą rzeczy nie zapewnią takiej wydajności jak zapytania SQL wykonywane bezpośrednio w bazie.

Bzdura, select to select. Większą wydajność możesz osiągać w przypadku bardziej złożonych operacji.
Stratę na wydajności masz jedynie na budowaniu zapytania w aplikacji, co jest praktycznie bez znaczenia w porównaniu z samymi operacjami I/O w bazie i transferem przez sieć. Za to zyskujesz niezawodność i nie tracisz czasu na poprawianie głupich literówek.

Bazy danych i oprogramowanie je obsługujące tworzy się od dziesięcioleci i jakoś działało nawet jak nie było testów jednostkowych wg obowiązującej dzisiaj definicji.

Odpowiem po Twojemu - porównaj nakład pracy na ręczne pisanie SQL, debugowanie go i poprawianie literówek, a na wygenerowanie dokładnie takiego samego kodu przez ORM automatycznie.

Poza tym czy wybrać code first /model first / database first to jest sprawa zależna od wielu czynników i wskazywanie tylko jednego rozwiązanie jako poprawnego jest trochę śmieszne.

A ktoś je tu wskazuje?

to zrób prosty MessagBox otwierany z "formularza głównego" w którym wyświetli się lista będąca wynikiem zapytania z parametrem przekazanym z z tego formularza, a następnie zwróć wynik wyboru użytkownika do pola TextBox "formularza głównego" i porównaj nakład pracy.

Ale po co? Nic nie zmieni to faktu, że WebFormsy to komponentowe i zdarzeniowe programowanie dla weba. Jeśli temu przeczysz, to znaczy, że nie masz o nich pojęcia.

kilka miesięcy temu w swojej aplikacji zrezygnowałem własnie z wyszukiwania realizowanego bezpośrednio w kodzie programu i przeniosłem je do procedury przechowywanej. Procedura wyszła najdłuższa jaką w życiu napisałem, ale szybkość wyszukiwania spadła z minut na sekundy.

Co niczemu nie dowodzi, ewentualnie tylko potwierdza to, o czym pisałem. Wyszukiwanie to nie jest CRUD.

Pisanie SQL ręcznie to okradanie siebie z czasu i klienta z pieniędzy.