Temat: Technologia dostępu do danych. Jaką wybrać, jakiej się...

wygląda dość prosto.. rzeczywiście tak jest czy jak zacznę pisać to się okaże jakaś masakra?

Temat: Technologia dostępu do danych. Jaką wybrać, jakiej się...

A przeczytałeś któryś z tutoriali na ten temat?

Powinieneś na tej podstawie wyrobić sobie jakieś zdanie.

Każda technologia może Cię uwalić go przyszłej gwiazdki w nietypowych (brak definicji) przypadkach.

Jeśli nie będziesz stosował dziedziczenia tabel, nie będziesz przejmował się równoczesnym dostępem do danych, wystarczą Ci domyślne generatory kluczy, wersjonowania krotek, to będzie to proste.

Na początku musisz mieć tabele i zmapowane na nie klasy. Nie musi być 1:1 - np. w przypadku relacji m:n potrzebujesz 3 tabel, ale tylko 2 klas. Oczywiście nie musi być tak różowo i pewnie zamienisz m:n na 1:n i n:1...

Są dwie szkoły. Jedna, ta nowoczesna, mówi, że powinno się przechodzić od UMLa do tabel w bazie (obiektowo), druga (ta dinozaurowa), że narysować ERD, a potem zrobić odpowiednie mapowania do obiektów i wpleść je w ERD. Ja aktualnie wykorzystuję to drugie podejście (stare przyzwyczajenia z metodyki SSADM ze studiów - wolę "kurze łapki" niż strzałki - to wszystko :] ). Mam ERD tak przygotowany, że potem bez problemu wplatam go w UML. Ty już podejdź bardziej profesjonalnie - od UMLa do tabel w bazie.

Czyli masz ERD/UML, z tego generujesz (odpowiednio) tabele lub klasy (jakimś generatorem kodu). Albo piszesz je ręcznie.

Gdy masz tabele i klasy, to teraz trzeba dokonać mapowania klasy na tabele - która kolumna w bazie odpowiada jakiemu polu w klasie. Można to zrobić przez pliki HBM.XML, można - jak wskazano - przez atrybuty w klasie.

Są programy do automatycznego tworzenia klas C# i plików HBM.XML na podstawie definicji bazy danych. Np. wtyczka CakePHP do DBDesignera (PHP, ale generuje także klasy C#).

Namęczysz się trochę, zanim poprawnie utworzysz mapowania 1:n jedno i wielokierunkowe, trzeba to "złapać" pod kątem sensu (co określa co i na co wskazuje), nie składni (ta jest bardzo prosta).

A potem to już schemat. Tworzysz sesję, wyciągasz obiekt, modyfikujesz obiekt, zapisujesz obiekt... Tworzysz obiekt, podajesz wartości pól, zapisujesz. Znajdujesz obiekt, usuwasz.

I to może być wszystko.

A możesz dowolnie komplikować zapytania, parametryzować je, męczyć się z wielodostępem (blokowanie optymistyczne, pesymistyczne), możesz tworzyć "triggery" (tzw. interceptory). Możliwości masz mnóstwo, lecz pewnie w szczególnych sytuacjach coś nie będzie tak, jak chcesz. Wtedy zaczną się kombinacje i szukanie brudnych "workaround".

Nie zagwarantuję Ci, że wszystko będzie proste, jak funkcja liniowa, ale MOŻE być proste.

Popatrz z tej strony. NHibernate to odnoga Hibernate dla Javy, a to z kolei implementacja ogólnej zasady ORM. Korzystają z tego dziesiątki (setki?) tysięcy programistów. Gdyby było do kitu, zarzucono by projekt.

Oczywiście możesz subiektywnie stwierdzić, że Ci to nie pasuje. Ale nie będziesz wiedział, zanim nie spróbujesz.

A IMHO warto.

Na początek nie rzucaj się od razu na napisanie projektu od zera w nowej technologii.

Napisz sobie parę konsolowych programików, naucz się po kolei podstaw. Najpierw konfiguracji. Czy to AppConfigiem, czy to z wskazanym XMLem, czy to z kodu programu. Potem przetraw insert, update, delete, select... Jak Ci to zadziała, poczujesz, że panujesz nad tym, to następny krok - relacje. Pobaw się relacjami 1- i 2-kierunkowymi 1:n, 1:1, m:n, poćwicz generowanie kluczy różnymi metodami (pamiętaj o bardzo przydatnym, ale "ciężkim" typie GUID). Potem poczytaj o wielodostępie do danych i pobaw się tym.

Jak to opanujesz, dopiero bierz się za poważny projekt. Inaczej może to być frustrujące i stracisz więcej czasu, niż trzeba.Adrian Olszewski edytował(a) ten post dnia 11.03.09 o godzinie 04:07

Temat: Technologia dostępu do danych. Jaką wybrać, jakiej się...

dzięki za te jakże obszerne wypowiedzi :)