Wzorce projektowe - bazodanowe, pytanie

Witam,

Otóż dużo ostatnio czytam o wzorcach projektowych ( DAO, Active Record, Repozytorium ). Otóż stworzyłem już dawno do nauki bazę danych w accesie ( na jedno wyjdzie czy zrobię to także w Oracle czy Sql Server ). Zaimplementowałem klasę bazową, z metodami virtualnymi i przedstawiałem każdą encje w postaci klasy ( uwaga nie klasa generyczna! Nie repozytorum! ). Dalej działo się już standardowo, metody wywoływane polimroficznie, przyjmujące różne argumenty, wyświetlające wyniki pobrane z bazy danych w różny sposób. Suma sumarum wykorzystałem tutaj obiektowość pełną parą.

Zainteresowałem się wzorcem Repozytorium, ale mam 0 pojęcie o wzorcach w c# a chciałbym z nim się związać. Ten wzorzec to dobry sposób na naukę klas/typów generycznych no i MVC. Mam nooby'styczne pytanie. Nic w opisie Repozytoruum nie ma o łączeniu się z bazą itp. Dla mnie to abstrakcja oprócz tego, że np. rozumiem tworzenie tych klas. Ale w żaden sposób nie mam pojęcia jak one są dodawane do bazy.

Ex. http://www.pzielinski.com/?p=281

Pozdrawiam i liczę chodź na linki i wskazówki.

Pozdrawiam.

Do małych aplikacji bazodawych jaki wzorzec byście zalecali? Jest ich masa i chyba będę musiał zaopatrzeć się w Książkę. Czy może w żaden wzorzec i korzystać po prostu z obiektowości języka i executowania komend.

Pozdrawiam

Repository może na przykład wewnętrznie korzystać z ORM (czyli NHibernate, innych ORM dla .NET praktycznie nie ma), które to samo potrafi zmapować obiekty na tabele na podstawie swojej konfiguracji.
To jest całkiem zgrabne rozwiązanie, lepsze jest chyba tylko pozbycie się repository i pozostawienie samego NHibernate, które samo z siebie implementuje wzorzec unit of work.

Czasem mi się wydaje, że zamiast pchać się we wzorce projektowe lepiej napisać aplikacyjkę, która będzie tylko graficznym przedstawicielem bazy danych ( umożliwi wszystko co można robić na bazie ). Mowa tutaj np. o bazie w Accesie, zdefiniowaniu dla każdej tabeli w db klasę metody i tyle. Dosyć proste, przyjemne, niezła możliwość rozbudowny, optymalizacja zapytań swoją drogą przy kobyłach. Nie mapujemy nic, nie mamy do czynienia z ORM, który jest nie do końca wspierany przez producentów baz danych.

Proszę o odpowiedź :-) Pozdrawiam

http://www.codeguru.pl/artykul/wydruk_pdf/2218

Lepiej się już nie da wytłumaczyć, ale w dalszym ciągu nie wiem, gdzie zdeklarować przy takich operacjach połączenie skoro działam z Accesem :-) Być może nie potrafię sobie tego wyobrazić ( pewnie błędnie to robię ), ale liczę chociaż na linki czy odzew :-)

Dobra Active Record już chyba zaczaiłem :-) Dziś wieczorem skończę zabawę to tutaj się podzielę. Pozdrawiam.

Ciekawski napisał(a):

Czasem mi się wydaje, że zamiast pchać się we wzorce projektowe lepiej napisać aplikacyjkę, która będzie tylko graficznym przedstawicielem bazy danych ( umożliwi wszystko co można robić na bazie ). Mowa tutaj np. o bazie w Accesie, zdefiniowaniu dla każdej tabeli w db klasę metody i tyle. Dosyć proste, przyjemne, niezła możliwość rozbudowny, optymalizacja zapytań swoją drogą przy kobyłach. Nie mapujemy nic, nie mamy do czynienia z ORM, który jest nie do końca wspierany przez producentów baz danych.

Proste i przyjemne? Musisz napisać masę identycznego kodu, który nie wnosi żadnej wartości biznesowej, a zajmuje się infrastrukturą.
Nic nie mapujemy? W sensie nie mamy żadnych obiektów encji, jedynie wysyłamy wygenerowane w aplikacji polecenie SQL do bazy? Tak, to dobre podejście... Pod warunkiem, że żyjemy w latach 80tych XX wieku. Programowanie strukturalne jest znacznie mniej elastyczne od obiektowego.
Ostatnie zdanie to w ogóle jakieś takie dziwne stwierdzenie. Czemu niby jacyś producenci baz danych mieliby wspierać ORM? To ORM ma wspierać SZBD, a nie odwrotnie.

somekind już czytałem Twojego posta i to, że bierzesz udział w projekcie opartym na OMR :-) Muszę po prostu przetrawić NHibernate i wtedy coś więcej się wypowiem :-) Ale jako noob twierdzę, że ORM-em można się bawić w momencie kiedy mamy do czynienia z czymś naprawdę dużym, fakt, że wysyłanie zapytań do bazy jest banalne, ORM jest na pewno o wiele trudniejszy, ale tak jak piszesz na pewno o wiele bardziej elastyczniejszy, ale o tym dowiem się tworząc pierwszą aplikację NHibernate :-)

Pozdrawiam

Tak ostatnie zdanie miało być takie, że ORM nie wspiera wszystkich producentów baz danych :-)

Ciekawski napisał(a):

Ale jako noob twierdzę, że ORM-em można się bawić w momencie kiedy mamy do czynienia z czymś naprawdę dużym, fakt, że wysyłanie zapytań do bazy jest banalne, ORM jest na pewno o wiele trudniejszy, ale tak jak piszesz na pewno o wiele bardziej elastyczniejszy, ale o tym dowiem się tworząc pierwszą aplikację NHibernate :-)

Dlaczego niby ORM miałby być trudniejszy? Ty definiujesz klasy i tworzysz obiekty, a ORM daje Ci metody do ich zapisywania i odczytywania. Dużo trudniejsze i znacznie bardziej czasochłonne jest ręczne napisanie wszystkich operacji CRUD w oparciu o SqlCommand i SqlReader (bo jak rozumiem, to tak robisz teraz) i nie popełnienie błędu.

Ciekawski napisał(a):

Tak ostatnie zdanie miało być takie, że ORM nie wspiera wszystkich producentów baz danych :-)

No zgoda, ale w takim razie trzeba wybrać ORM, który obsługuje bazę, której chcesz użyć. Przy czym i tak najpopularniejsze bazy są obsługiwane.