Tworzenie interfejsów do bazy danych z wykorzystaniem technologii ADO

Prezentacja na temat: "Tworzenie interfejsów do bazy danych z wykorzystaniem technologii ADO"— Zapis prezentacji:

1

2 Tworzenie interfejsów do bazy danych z wykorzystaniem technologii ADO
Tworzenie interfejsów do bazy danych z wykorzystaniem technologii ADO.Net informatyka +

3 Obiektowe spojrzenie na bazę danych
Baza danych Obiekt „BazaDanych” Model logiczny bazy danych Atrybuty obiektu Procedury składowane Metody obiektu

4 1.Zapytanie o stan konta A 2.Odpowiedź – stan Konta A
Wykonane Interfejs „Form” Wykonaj przelew z konta A na konto B SQLServer Środowisko śieciowe 1.Zapytanie o stan konta A 2.Odpowiedź – stan Konta A 3.Rozpoczęcie transakcji 4.Odpowiedź na polecenie 5.Zmiejszenie stanu konta A 6.Odpowiedź na polecenie 7.Zwiekszenie stanu konta B 8.Odpowiedź na polecenie 9. Zakończenie transakcji 10.Odpowiedź na polecenie

5 A teraz inne podejście ????????????

6 Metoda „WykonajPrzelew”
Iterfejs „Form” SQL Server Wykonane Środowisko śieciowe Wykonaj przelew z konta A na konto B 1.Wykonaj metodę „…Przelew” 2.Odpowiedź z metody

7 Dostęp do baz danych (.NET Framework 3.5)
Aplikacja Dostęp do danych Baza danych Tematem szkolenia są mechanizmy organizowania dostępu do baz danych w aplikacjach budowanych w oparciu o .NET Framework 3.5 i Visual Studio 2008 Zakres szkolenia nie wyczerpuje wszystkich powszechnie stosowanych rodzajów organizowania dostępu do danych, skupia się wokół kilku wybranych. Celem szkolenia jest zaprezentowanie ogólnej koncepcji projektowania architektury aplikacji z uwzględnieniem wydzielonej warstwy dostępu do danych, oraz zaprezentowanie kilku podejść do implementacji takiej warstwy, oraz wskazanie ich najistotniejszych wad i zalet. Do implementacji przykładów wykorzystany został język C# Do szkolenia dołączony został kompletny kod źródłowy prezentowanej aplikacji oraz kopia zapasowa lub skrypt SQL tworzący przykładową bazę danych. Omawiane w ramach szkolenia zagadnienia mają za zadanie zasygnalizować podstawy poszczególnych koncepcji organizowania kodu dostępu do danych oraz na ich podstawie zobrazować ewolucję technik stosowanych przy tworzeniu aplikacji bazodanowych. Tendencja ta polega na coraz bardziej abstrakcyjnym traktowaniu mechanizmów dostępu do baz danych, pozostawianiu coraz większego obszaru kodu automatycznym generatorom przy jednoczesnym położeniu nacisku na modelowanie struktur danych z punktu widzenia biznesowego. Naturalnym kosztem takiego podejścia bywa spadek wydajności, choć nie jest to regułą. Różne implementacje gotowych narzędzi mogą cechować się architekturą sprzyjająca wzrostowi wydajności, przy jednoczesnym wyeliminowaniu większości typowych błędów popełnianych przez programistów przy tworzeniu kodu dostępu do danych. informatyka +

8 Wymagania wstępne informatyka +
Podstawowa znajomość Visual Studio (.NET 2003, 2005 lub 2008) Podstawowa znajomość języka C# Podstawowa znajomość serwera baz danych MS SQL Server (2000, 2005, 2008) Szczere chęci do nauki ;-) Słuchacze powinni posiadać już umiejętność posługiwania się środowiskiem Visual Studio, lub jakimkolwiek innym IDE. Ze względu na wykorzystywany w przykładach język C#, słuchacze powinni orientować się w jego składni i rozumieć podstawowe pojęcia programowania obiektowego. Mile widziana będzie także choć powierzchowna znajomość nowych elementów języka C# (typy anonimowe (anonymous types), metody rozszerzeń (extension methods), wyrażenia lambda (lambda expressions)). Znajomość baz danych powinna obejmować oprócz posługiwania się takimi obiektami jak tabele, widoki, funkcje i procedury składowane, także umiejętność tworzenia zapytań SQL. informatyka +

9 Agenda Architektura aplikacji korzystających z baz danych Jaką architekturę wybrać i kiedy? Na co zwrócić uwagę, żeby później nie pluć sobie w brodę? Co oferuje .NET Framework w zakresie dostępu do danych? Planowanie i implementacja warstwy dostępu do danych Metoda „na piechotę” Data Access Application Block (Enterprise Library) LINQ to SQL mało? ... krótki przegląd innych możliwości Podsumowanie i wnioski Kolejnym omawianym zagadnieniem jest kwestia doboru adekwatnej do wymagań architektury rozwiązania. Pomimo istnienia dużej liczby istniejących rozwiązań, szablonów, koncepcji oraz wzorców, nie ma architektury idealnej. Do rozwiązania konkretnego problemu można zastosować wiele podejść, natomiast każde z nich niesie ze sobą swoją specyfikę, która w znacznym stopniu może rzutować na to, jak sprawdzi się przy realizacji konkretnego przedsięwzięcia. Bardzo często w praktyce okazuje się, że zbyt pochopne przyjęcie architektury rozwiązania może powodować powstawanie na różnych etapach zaawansowania projektu różnych, nieprzewidzianych problemów, które zwykle powodują powstanie opóźnień przy realizacji harmonogramu, lub wręcz wymuszają zmianę koncepcji projektu już w trakcie jego realizacji. Tego typu zdarzenia potrafią doprowadzić nawet do upadku projektu, co nie należy do rzadkości, jeśli weźmie się pod uwagę statystyki, które mówią , że tylko ok % projektów kończy się sukcesem. informatyka +

10 Architektura aplikacji
Nie ma architektury doskonałej Nie ma doskonałego procesu wytwórczego Każde z podejść sprawdza się różnie w różnych projektach “We know why projects fail, we know how to prevent their failure -- so why do they still fail?” Martin Cobb "Wiemy, dlaczego projekty upadają, wiemy jak zapobiec tym upadkom – więc dlaczego one ciągle upadają ?" Nie należy wierzyć w istnienie jednej, najlepszej i gwarantującej sukces architektury systemu, jak i samego procesu wytwórczego. Gdyby takowe istniały, to nie byłoby problemu z realizacją projektów. Warto wspomnieć słuchaczom o paradoksie Cobb’a: “We know why projects fail, we know how to prevent their failure -- so why do they still fail?” "Wiemy, dlaczego projekty upadają, wiemy jak zapobiec tym upadkom – więc dlaczego one ciągle upadają ?" Zagadnienia związane z tym jak podejść do realizacji konkretnego projektu, jaką zastosować metodykę, jaka architekturę rozwiązania są na tyle rozległe, że mogą stanowić temat na bardzo długi cykl szkoleń, w którym na każdym szkoleniu będziemy przekonywani o tym, że ta konkretna metoda jest najlepsza. W praktyce jedynym sposobem jest uczenie się na własnych błędach i zdobywanie doświadczenia przy kolejnych projektach, co pozwala w przyszłości łatwiej dobierać odpowiednie narzędzia do odpowiednich problemów. informatyka +

11 Architektura aplikacji
Kilka „oczywistych oczywistości” : Dostęp do danych jest uzyskiwany praktycznie w każdej aplikacji. Zwykle, jako ze źródła danych, korzysta się z bazy danych W kodzie aplikacji, jego znaczna część dotyczy pobierania/modyfikowania danych Po wdrożeniu aplikacji pojawia się konieczność jej rozwijania i ulepszania Kwestie związane z organizowaniem dostępu do danych są bardzo istotne, ze względu na to, że bywają wykorzystywane w większości tworzonych aplikacji. Bazy danych są najczęściej wykorzystywanym źródłem danych dla każdego rodzaju aplikacji. Nieistotne, czy tworzymy aplikację desktopową czy webową – będą one korzystać z danych przechowywanych w bazie danych. Zwykle dwa obszary w kodzie aplikacji są największe: logika aplikacji (zachowanie się interfejsu użytkownika) oraz dostęp do danych. Jeśli buduje się prostą aplikację, co do której mamy gwarancję, że po jej wyprodukowaniu możemy o niej zapomnieć i nigdy więcej do niej nie wracać, to nie ma potrzeby zawracania sobie głowy dbaniem o sensowność jej architektury. Częściej jednak tworzy się produkty, które później trzeba modyfikować i rozwijać. W takiej sytuacji brak przemyślanej architektury mści się na programistach okrutnie… Kod zawierający mechanizmy dostępu do danych bywa bardzo rozbudowany a do tego silnie związany ze strukturą bazy danych. Taka sytuacja powoduje, że nawet małe zmiany w bazie danych – na przykład zmiana nazwy kolumny – potrafi powodować konieczność nanoszenia zmian w bardzo wielu miejscach kodu aplikacji. Jeśli do tego doda się sytuację, w której różne osoby lub zespoły osób pracują nad bazą danych i aplikacją to wyłaniający się obraz nie jest wesoły… i tak tez bywa w rzeczywistości. Pojawia się propozycja zmiany w systemie, jest akceptowana, zaczyna się nanoszenie zmian w bazie danych i w aplikacji. Nagle okazuje się, że przeoczono jedno czy dwa miejsca, w których należało zmodyfikować kod i aplikacja zaczyna generować dziwne wyniki lub po prostu przestaje działać jakaś część funkcjonalności, która bywa nawet dość odległa od miejsca nanoszenia zmian. Często takie problemy ujawniają się dopiero w produkcyjnej wersji systemu… informatyka +

12 ochronę przed deszczem”
Architektura aplikacji c.d. W ciągu kilkudziesięciu ostatnich lat wypracowano cały szereg dobrych praktyk dotyczących zarówno samego procesu wytwarzania oprogramowania jak i planowania jego architektury W ramach wykładu zajmiemy się małym fragmentem tej dziedziny W praktyce ważne jest znalezienie rozsądnego kompromisu pomiędzy planowaną architekturą aplikacji, a czasem potrzebnym na jej zastosowanie i celowością korzystania z niej w konkretnej sytuacji WYMAGANIE: „Ma zapewnić ochronę przed deszczem” Należy zasygnalizować słuchaczom, że zajmować się będziemy niewielkim fragmentem bardzo rozległej i złożonej dziedziny jaka jest projektowanie systemów informatycznych. Prezentowane w dalszej części szkolenia zagadnienia nadają się do wykorzystania w małych i średnich systemach i nie brane są pod uwagę zagadnienia związane z niezawodnością, skalowalnością czy wydajnością systemu. Do tego sam zakres omówienia poszczególnych metod jest na tyle ograniczony, ze pozwala jedynie na zasygnalizowanie kluczowych założeń i zilustrowanie ich prostymi przykładami. Pozwoli jednak na zwrócenie uwagi słuchaczy na najistotniejsze elementy i ułatwi im szukanie dalszych kierunków zdobywania wiedzy i umiejętności w zakresie tworzenia aplikacji. Zaakcentować należy fakt, że każdy projekt jest w ostatecznym rozrachunku oceniany przez użytkowników i klientów. Użytkownicy oceniają go przez pryzmat łatwości posługiwania się nim, natomiast klient od strony biznesowej – np. o ile wdrożenie systemu skróciło czas realizacji zamówienia bądź wyeliminowało część popełnianych błędów lub spowodowało obniżenie kosztów przez lepszą alokacje zasobów itp.. Ani klient, ani użytkownicy nie będą raczej zainteresowani tym, jak zbudowany jest system „w środku”. Leży to natomiast w interesie osób, które go tworzą oraz będą w przyszłości utrzymywać lub rozwijać. Który wariant wybrać ??? informatyka +

13 Skupmy się na typowej, prostej architekturze warstwowej
Architektura aplikacji c.d. Skupmy się na typowej, prostej architekturze warstwowej Interfejs użytkownika Zwany warstwą prezentacji Zadanie: prezentować i pobierać dane Logika biznesowa Definiuje obowiązujące w systemie reguły Umożliwia realizację poleceń użytkownika Dostęp do danych „Odcięcie” wyższych warstw od szczegółów mechanizmu dostępu do danych Baza danych Składowanie danych Typowy model architektury systemu można zbudować z 3-4 warstw: Warstwy prezentacji jej celem jest przedstawianie danych użytkownikowi oraz umożliwienie mu modyfikowania tych danych, a także sterowania zachowaniem aplikacji może zawierać tzw. „logikę aplikacji” (np. regułę, że jeżeli opcja x jest zaznaczona, to użytkownik nie widzi pól y i z) Warstwy logiki biznesowej zawiera ona kod odpowiedzialny za realizację poszczególnych operacji biznesowych (np. złożenie zamówienia, przyznanie rabatu, itp.) zawiera także reguły biznesowe (np. „pracownik może przyznać rabat do 5%, a za zgodą managera do 20%”,”kwota na fakturze mus być większa od zera”) Warstwy dostępu do danych zawiera kod realizujący operacje komunikowania się z bazą danych i przekazywania jej poleceń pobrania/dodania/modyfikacji/usuwania danych może zawierać także mechanizmy pozwalające na konfigurowanie dostępu do danych (wybór serwera, sposobu łączenia się za bazą itp.) Warstwy danych zwykle jest to serwer baz danych baza danych zawiera tabele baza może także zawierać widoki, procedury składowane, funkcje użytkownika, wyzwalacze, które służą do ukrycia szczegółów implementacyjnych bazy przed aplikacjami z niej korzystającymi, bądź do zaimplementowania części lub całości logiki biznesowej W prostszych aplikacjach, warstwa logiki biznesowej „rozpływa się” i zawarta jest w warstwie prezentacji, warstwie danych lub w obu naraz). Bywa też zawarta w warstwie dostępu do danych. Wszelkie dalsze rozważania w ramach szkolenia będą dotyczyły warstwy dostępu do danych. informatyka +

14 Agenda Architektura aplikacji korzystających z baz danych Jaką architekturę wybrać i kiedy? Na co zwrócić uwagę, żeby później nie pluć sobie w brodę? Co oferuje .NET Framework w zakresie dostępu do danych? Planowanie i implementacja warstwy dostępu do danych Metoda „na piechotę” Data Access Application Block (Enterprise Library) LINQ to SQL mało? ... krótki przegląd innych możliwości Podsumowanie i wnioski Kolejne omawiane zagadnienie będzie dotyczyło wyznaczenia kilku prostych założeń, które ułatwiają tworzenie aplikacji w taki sposób, aby zapewnić sobie w miarę wysoką odporność aplikacji na zmiany przy zachowaniu przewidywalności nakładu pracy potrzebnej do realizacji zmian. informatyka +

15 Architektura aplikacji c.d.
„Jedyną stałą rzeczą w projekcie są zmiany” Aby uniknąć problemów przy rozbudowie i modyfikowaniu aplikacji: należy dobrze zdefiniować jakie operacje będą wykonywane na danych (interfejs warstwy dostępu do danych) należy wydzielić kod odpowiedzialny za przekazywanie poleceń do bazy danych i odbieranie od niej rezultatów w takim przypadku, aplikacja nie musi znać żadnych szczegółów (z jaką bazą się łączyć, jakie zapytanie wykonać, z jakiej procedury składowanej skorzystać itp..) łatwiej jest szacować nakład pracy potrzebny na implementację W przypadku modyfikowania lub rozbudowywania aplikacji, bardzo często trzeba zmienić strukturę bazy, dodać nowe cechy informacyjne, zmienić sposób realizowania operacji. Jeżeli kod aplikacji zawiera „wplecione” polecenia związane z komunikacja z bazą danych, to każda zmiana w bazie pociąga za sobą znaczne zmiany w kodzie aplikacji. Dodatkowo ten „wpleciony” kod jest zwykle pofragmentowany, często jest dublowany w wielu miejscach. Wszystko to powoduje, że trudno jest ocenić nakład pracy potrzebnej do dokonania niezbędnych zmian oraz łatwo jest przeoczyć jedno lub więcej miejsc, w których należało nanieść poprawki. To z kolei może prowadzić do niestabilnej i niepoprawnej pracy systemu. Jeżeli twórca zada sobie nieco trudu i przemyśli oraz zdefiniuje operacje niezbędne do zapewnienia aplikacji wymaganej funkcjonalności, to efektem będzie stworzenie „czarnej skrzynki”, która z punktu widzenia aplikacji oferuje jasno określony zestaw operacji i skrzętnie ukrywa przed nią sposób w jaki operacje te są realizowane. Takie podejście pozwala na niezależne modyfikowanie sposobu funkcjonowania „czarnej skrzynki” bez potrzeby informowania o tym aplikacji i co najważniejsze – bez modyfikowania kodu aplikacji Kod realizujący operacje komunikacji z bazą danych jest powtarzalny i budowany wg tych samych szablonów dla podobnych operacji. To powoduje, że z jednej strony można w wiarygodny sposób szacować nakład pracy potrzebny do zaimplementowania określonego zakresu funkcjonalności, z drugiej zaś powoduje, że programiści zaczynają szukać sposobów na uniknięcie pisana setny raz podobnego fragmentu kodu … co prowadzi wprost do powstania różnego rodzaju narzędzi ułatwiających i przyspieszających tworzenie kodu warstwy dostępu do danych. W ramach szkolenia przyjrzymy się właśnie bliżej kilku takim rozwiązaniom informatyka +

16 Agenda Architektura aplikacji korzystających z baz danych Jaką architekturę wybrać i kiedy? Na co zwrócić uwagę, żeby później nie pluć sobie w brodę? Co oferuje .NET Framework w zakresie dostępu do danych? Planowanie i implementacja warstwy dostępu do danych Metoda „na piechotę” Data Access Application Block (Enterprise Library) LINQ to SQL mało? ... krótki przegląd innych możliwości Podsumowanie i wnioski .NET Framework zawiera cały szereg klas pomocnych przy budowaniu mechanizmów dostępu do danych. Klasy te ewoluują od .NET Framework 1.0 i są obecnie bardzo dobrze dostosowane do potrzeb programistów. Na przestrzeni dziesięciu ostatnich lat okazywało się wielokrotnie, że niektóre koncepcje nie sprawdzały się w praktyce (np. ze względu na kiepską wydajność, ograniczone możliwości). Były jednak ustawicznie rozwijane i dzięki temu dziś programiści maja o wiele potężniejsze i wygodniejsze narzędzia niż kilka, kilkanaście lat temu. Trzeba zwrócić uwagę na fakt, że na programistów i projektantów czyha coraz więcej marketingowych pułapek – na pokazie jakiejś nowej technologii prezenter pokazuje jak łatwo i szybko da się „wyklikać” gotową aplikację. Po 10 – 20 minutach mamy już działający projekt… Problemy zaczynają się, gdy damy się nabrać i pójdziemy ta drogą w ‘prawdziwym” projekcie. Okazuje się, że prezentowane narzędzia nie uwzględniają bardziej zaawansowanych scenariuszy, lub łatwo się je tworzy, ale modyfikowanie bywa udręką. Często można natrafić w Internecie na głosy „purystów”, którzy negują sensowność stosowania technologii czy narzędzia X, zachwalając stare dobre Y. Podobnie jest z entuzjastami nowych rozwiązań. Niestety człowiek najlepiej uczy się na własnych błędach. W przypadku .NET programiści z większym stażem dysponują już dobrą perspektywą i mogą porównać jak budowało się kod jeszcze kilka lat temu, a jak teraz. Nie ulega wątpliwości, że obecnie jest dużo lepsze wsparcie ze strony narzędzi, ale jednocześnie stopień złożoności budowanych aplikacji także znacznie wzrósł, co powoduje, że proces trwa nadal – większa złożoność, lepsze narzędzia… programista musi za tym nadążać i potrafić szybko uczyć się nowych technologii, by wykorzystywać ich możliwości w pełni i realizować projekty zgodnie z założeniami. informatyka +

17 Jak skorzystać z bazy danych?
.NET Framework 3.5 oferuje kilka interfejsów pomocnych przy komunikowaniu się z bazami danych. Klasy implementujące te interfejsy pełnią następujące role: IDbConnection odpowiedzialna za zdefiniowanie i zarządzanie połączeniem z bazą danych IDbCommand odpowiedzialna za zbudowanie polecenia, które będzie wysłane do bazy danych za pośrednictwem połączenia IDataReader umożliwia odbieranie rezultatu wykonania polecenia przez bazę danych IDbParameter pozwala na definiowanie parametrów polecenia przekazywanego do bazy danych, lub odbierania wartości parametrów wyjściowych IDataAdapter pozwala na zdefiniowanie operacji CRUD (Create, Read, Update, Delete) dla określonej tabeli w bazie danych .NET Framework w wielu miejscach korzysta z modelu dostawców (providers). Dostęp do danych także oparty jest na tym modelu. Z grubsza polega to na zdefiniowaniu ogólnych interfejsów dla usług oferowanych przez dostawcę (np. połączenie z bazą powinno umożliwiać otwarcie połączenia oraz jego zamknięcie, a także zwracać informacje o jego aktualnym stanie – interfejs IDbConnection posiada zdefiniowane metody Open(), Close() oraz właściwość State). Każdy mechanizm służący do nawiązywania połączenia z konkretną bazą danych zawiera klasy implementujące interfejsy dostawcy. Standardowo .NET Framework zawiera dostawców: ODBC Data Provider OLEDB Data Provider SQLClient Data Provider Każdy z nich zawiera zestaw klas umożliwiających dostęp do różnych rodzajów źródeł danych. ODBC – dostęp do źródeł z wykorzystaniem ODBC (Open DataBase Connectivity), OLEDB (Object Linking and Embedding, Database) – następca ODBC, ma większe możliwości. SQLClient –dedykowany dostawca dla SQL Server-a Jeżeli musimy się łączyć z inna bazą danych lub dowolnym innym źródłem – wystarczy uzyskać odpowiedniego dostawcę od producenta bazy (np. Oracle) lub wręcz napisać własnego. W ramach szkolenia nie będziemy zajmować się klasami DataSet oraz DataTable, gdyż są one bardzo dobrze udokumentowane i opisane zarówno od strony ich zalet jak i wad. Do tego metoda wykorzystująca do komunikacji za bazą danych obiekty typu TableAdapter, DataAdapter, DataSet i DataTable jest najczęściej opisywana w różnego rodzaju materiałach dotyczących budowania mechanizmów dostępu do danych. informatyka +

18 Agenda Architektura aplikacji korzystających z baz danych Jaką architekturę wybrać i kiedy? Na co zwrócić uwagę, żeby później nie pluć sobie w brodę? Co oferuje .NET Framework w zakresie dostępu do danych? Planowanie i implementacja warstwy dostępu do danych Metoda „na piechotę” Data Access Application Block (Enterprise Library) LINQ to SQL mało? ... krótki przegląd innych możliwości Podsumowanie i wnioski W ramach tej części szkolenia poruszone zostaną zagadnienia związane z konkretnymi sposobami implementowania kodu dostępu do danych. Warto zdawać sobie sprawę, że nawet w najbardziej wyrafinowanych mechanizmach, gdzieś w głębi korzysta się z tych samych , podstawowych klas dostarczonych przez .NET Framework. Z tego powodu pierwszy sposób tworzenia kodu dostępu do danych będzie polegał na wykorzystaniu tych właśnie elementarnych klas i metod. Dobre ich zrozumienie ułatwia diagnozowanie pojawiających się problemów a także ułatwia zrozumienie sposobu działania bardziej złożonych rozwiązań. Naturalną konsekwencją tworzenia kodu korzystając z podstawowych klas jest poczucie żmudności, wielokrotnego pisania podobnych fragmentów kodu itp. Prowadzi to do budowania rozwiązań „wyższego poziomu”, które obudowują podstawowe klasy i typowe sposoby korzystania z nich w wygodniejszą formę, często wzbogacona o dodatkowe mechanizmy (np. obsługa błędów, wykrywanie konfliktów, śledzenie zmian) informatyka +

19 Dzienniczek Ucznia Na początek… informatyka +
Potrzebujemy pomysłu na przykładową aplikację bazodanową… …Są jakieś? …i tak nie mamy dość czasu, żeby je przedyskutować ;-) W takim razie proponuje skorzystać z wcześniej przygotowanego: Dalsze przykłady wykorzystania konkretnych sposobów uzyskania dostępu do baz danych będą oparte na przykładowej aplikacji. W dołączonym do szkolenia kodzie – interfejsy użytkownika (desktopowy i webowy) są już zaimplementowane, natomiast my skupimy się na stworzeniu kodu warstwy dostępu do danych. Przykładowa aplikacja jest bardzo prosta, ma jasno sformułowane wymagania, co ułatwia właściwe jej zaprojektowanie. Głównym obszarem naszego zainteresowania nie będzie architektura aplikacji jako całość, a jedynie jej część związana z mechanizmami dostępu do danych. Dzienniczek Ucznia informatyka +

20 Wymagania stawiane aplikacji
Dzienniczek ucznia ma umożliwiać: Wyświetlenie listy uczniów Wystawienie oceny ucznia z wybranego przedmiotu Wyświetlenie średniej arytmetycznej ze wszystkich ocen ucznia Wyświetlenie listy wszystkich ocen ucznia Wyświetlenie listy ocen uczniów z wybranego przedmiotu Podane wymagania stanowią podstawę budowania funkcjonalności aplikacji oraz warstwy dostępu do danych. W aplikacji stworzono już prostą warstwę biznesową, która zawiera klasy odpowiadające encjom biznesowym ( Student (uczeń), Note (ocena), Subject(przedmiot) ) Zdefiniowano także interfejs IStudentNotesDB, który definiuje wszystkie metody niezbędne do zapewnienia wymaganej funkcjonalności w zakresie dostępu do danych z bazy. Klasy te powstały jako prosta konsekwencja przeanalizowania wymagań stawianych aplikacji. Pozwalają na zdefiniowanie funkcjonalności warstwy biznesowej, a co za tym idzie także jej zapotrzebowania na operacje na danych w bazie. Typowe „tutorialowe” rozwiązanie polegałoby na przeciągnięciu tabel z bazy do obszaru roboczego odpowiedniego narzędzia, co spowodowałoby wygenerowanie klas (dziedziczących z DataSet oraz TableAdapter). Następnie obiekty tych klas byłyby wykorzystywane jako nośnik danych (DataSet, DataTable, DataRow, DataColumn, DataRelation itp.) oraz jako implementacja operacji na danych (TableAdapter). Do celów dydaktycznych przyjęliśmy nieco inne rozwiązanie. Nie jest nam potrzebna cała, bogata funkcjonalność klasy DataSet. Potrzebujemy kilku, prostych klas będących nośnikami danych (encjami biznesowymi) oraz klasy oferującej zestaw operacji na encjach biznesowych (zwracanie encji i kolekcji encji, modyfikowanie i dodawanie nowych encji itp.). Zdefiniowany zestaw operacji został sformalizowany w postaci klasy SchoolController. Ta właśnie klasa będzie korzystała z warstwy dostępu do danych. informatyka +

21 Struktura aplikacji informatyka +
Przygotowane zostało rozwiązanie (solution) zawierające projekty niezbędne do zademonstrowania funkcjonowania aplikacji i mechanizmów dostępu do danych. Struktura rozwiązania (solution) oddaje warstwowy charakter architektury aplikacji. Ze względu na ograniczenia czasowe i zakres szkolenia rozwiązanie jest uproszczone. Rozwiązanie składa się z projektów pogrupowanych w folderach (solution folder) odpowiadających warstwom aplikacji: Presentation Layer zawiera dwa projekty – aplikację desktopową (Windows forms) oraz webową, oferujące funkcjonalność dzienniczka ucznia. Pozwalają one na prezentację listy uczniów, listy przedmiotów, sprawdzenie średniej ocen ucznia oraz wystawienie nowej oceny uczniowi z wybranego przedmiotu. Business Logic Layer zawiera klasy odpowiadające encjom biznesowym (uczeń, przedmiot, ocena) oraz klasę SchoolController oferująca metody odpowiadające wymaganiom. Cel budowania takich klas omówiliśmy na poprzednim slajdzie. Common zawiera definicję interfejsu warstwy dostępu do danych, który będzie miejscem styku warstwy biznesowej i dostępu do danych. Interfejs ten został specjalnie wydzielony dla podkreślenia jego roli – kontraktu pomiędzy warstwa biznesową a warstwa dostępu do danych. Dodatkowo jego zdefiniowanie w osobnym projekcie pozwala na samodzielne dystrybuowanie go jako specyfikacji komunikacji z warstwą dostępu do danych, oraz ułatwia planowanie referencji pomiędzy projektami. Data Access Layer zawiera trzy projekty odpowiadające trzem sposobom tworzenia kodu dostępu do danych (które będą omawiane w ramach szkolenia) . Dwa pierwsze z nich mogą być stosowane wymiennie w aplikacji desktopowej (co jest zapewnione przez odpowiednie zaprojektowanie klasy SchoolController i jej konstruktora). Trzeci sposób eliminuje konieczność własnoręcznego tworzenia klas odpowiadających encjom biznesowym i dlatego został wykorzystany w drugiej wersji aplikacji – w aplikacji webowej. informatyka +

22 Warstwa prezentacji informatyka +
Warstwa prezentacji zawiera dwie aplikacje (desktopowa i webowa). Obie współpracują z ta samą baza danych i wykorzystują różne metody dostępu do danych. Aplikacje są bardzo proste, a ich rola sprowadza się do zaprezentowania działania mechanizmu dostępu do danych w możliwie łatwy sposób, tak, aby nie komplikować projektu i nie zaciemniać szczegółów korzystania z warstwy dostępu do danych. W projektach realizowanych „naprawdę” stosowane są różnego rodzaju podejścia i wzorce, które mają przynieść określone efekty (ułatwić modyfikowanie i rozwijanie aplikacji, zapewnić skalowalność itp.). Nie są one jednak tematem tego szkolenia i nie zostały wykorzystane przy tworzeniu przykładowych aplikacji. Obie przykładowe aplikacje korzystają z tej samej bazy danych i można uruchamiać je jednocześnie obserwując wyniki działań podejmowanych w obu aplikacjach. W skład aplikacji desktopowej wchodzi jedna forma (MainForm), na której można korzystać z całej funkcjonalności przewidzianej dla dzienniczka ucznia. W przypadku aplikacji webowej, podobna funkcjonalność została podzielona na kilka osobnych stron i elementów: Dzienniczek.Master – masterPage dla projektu (szablon układu strony ze zdefiniowanymi blokami na zawartość) Default.aspx – strona główna aplikacji StudentList.aspx – strona zawierająca listę uczniów w formie tabeli. Dla każdego ucznia jest tam umieszczony link umożliwiający przejście do wystawiania ocen. SubjectList.aspx – strona zawierająca listę przedmiotów Addnote.aspx – strona umożliwiająca wystawienie uczniowi oceny z określonego przedmiotu. informatyka +

23 Warstwa biznesowa informatyka +
Warstwa biznesowa w przykładowej aplikacji jest tworzona nieco „na siłę”. Spokojnie można by się bez niej obejść i korzystać wprost z obiektów SqlDataReader zwracanych z warstwy dostępu do danych. Idąc dalej tym tropem, można by podpinać te obiekty bezpośrednio do kontrolek na formatkach (potrafią one obsługiwać SqlDataReader jako źródło danych). Doprowadziłoby to jednak do sytuacji, w której logika biznesowa byłaby rozproszona i realizowana we fragmentach przez różne metody obsługi zdarzeń generowanych przez kontrolki formatki. O ile takie rozwiązanie da się stworzyć, to jego modyfikowania raczej się twórcy nie zazdrości… Celem utworzenia wydzielonej warstwy biznesowej oprócz umieszczenia w jednym miejscu logiki, było porównanie nakładu pracy potrzebnego do realizacji warstwy biznesowej oraz dostępu do danych (szczególnie przy wykorzystaniu LINQ to SQL, które eliminuje konieczność samodzielnego tworzenia encji biznesowych) Projekt DataLayerInterfaces stanowi wspomniany już wcześniej kontrakt, pomiędzy warstwą biznesową a warstwą dostępu do danych. Kontrakt ten będziemy wypełniać poprzez tworzenie w warstwie dostępu do danych klas implementujących interfejs IStudentNotesDB. informatyka +

24 Klasy warstwy biznesowej
Istotne jest zaakcentowanie słuchaczom faktu wydzielenia encji biznesowych. Zrobiono to w celu uniknięcia operowania w warstwie prezentacji pojęciami i obiektami reprezentującymi rekordy z bazy danych. Jedyną klasą, której metody będą wywoływane z poziomu warstwy prezentacji jest klasa SchoolController. Oferuje ona pełna funkcjonalność interfejsu IStudentnotesDB, a dodatkowo będzie odpowiedzialna za powołanie instancji odpowiedniej klasy warstwy dostępu do danych i wykorzystanie jej do komunikacji z bazą danych. Pozwoli nam to łatwo przełączać aplikacje na korzystanie z różnych klas dostępu do danych. Przykładowo jeżeli użytkownik z poziomu aplikacji wybierze opcję wyświetlenia listy uczniów, to zostanie stworzona instancja klasy SchollController, następnie zostanie wywołana jej metoda GetStudentList, która zwróci generyczną listę obiektów typu Student, który to typ z kolei zawiera właściwości odpowiadające cechom informacyjnym przechowywanym w bazie danych. Takie podejście pozwala uniknąć wielu błędów przy tworzeniu aplikacji, gdyż mamy tu do czynienia z silną kontrolą typów i ewentualne pomyłki będą wykryte już na etapie kompilacji kodu, a nie dopiero po uruchomieniu. Na diagramie brak jest klas implementujących interfejs IStudentNotesDB. Zostaną one utworzone przez nas w ramach dalszego ciągu szkolenia (w warstwie dostępu do danych). Metody klasy SchoolController operują na encjach biznesowych zdefiniowanych w pozostałych klasach widocznych na diagramie. Jej rola polega na pobraniu z bazy danych niezbędnych danych oraz na utworzeniu na ich podstawie instancji encji biznesowych i zwróceniu ich. Przykładowo metoda GetStudentList po skorzystaniu z warstwy dostepu do danych otrzyma obiekt SqlDataReader, po którym będzie iterować tworząc za każdym razem nową encję biznesową, inicjując ją danymi z bazy i dodając do listy, która zostanie ostatecznie zwrócona przez metodę. informatyka +

25 Definicja interfejsu IStudentNotesDB
definiuje operacje, które będą wykonywane na danych korzysta z interfejsu IDataReader Jest podstawą do budowania implementacji warstwy dostępu do danych Interfejs IStudentNotesDB pełni role kontraktu zawieranego pomiędzy warstwą biznesową a warstwą dostępu do danych. Definiuje on listę operacji, które będą udostępniane przez warstwę dostępu do danych, a z których będzie korzystała warstwa biznesowa. Zdefiniowanie takiego interfejsu pozwala na równoległe prowadzenie prac w obu warstwach, gdyż nie trzeba czekać aż warstwa dostępu do danych będzie zawierała gotową implementację. Z poziomu warstwy biznesowej można korzystać z interfejsu, do czasu, gdy gotowa będzie implementacja. Ze względu na prostotę rozwiązania i wysoką wydajność skorzystano z mechanizmu zwracania danych poprzez interfejs IDataReader, który zapewnia szybki, jednokierunkowy odczyt danych rekord po rekordzie. Rozwiązanie to jest najprostsze a zarazem jedyne. Pozostałe mechanizmy korzystają z DataReadera wewnętrznie i przetwarzają pobrane za jego pomocą dane do pożądanej postaci. Jako przykład można podać klasę DataAdapter, która zawiera metody pozwalające napełnić danymi obiekt DataSet, a także zaktualizować zmodyfikowane w nim dane w bazie. Odbywa się to poprzez utrzymywanie wewnątrz DataAdaptera czterech zestawów obiektów SqlConnection i Sqlcommand oraz zwracanych przez nie SqlDataReaderów. Te cztery zestawy odpowiadają operacjom CRUD (Create, Read, Update , Delete ) zwanych czasem SCUD (Select, Create, Update, Delete). Dane pobrane za ich pomocą są przechowywane w obiektach DataTable wchodzących w skład DataSetu informatyka +

26 Diagram bazy danych informatyka + skrajnie proste rozwiązanie
zawiera przykładowe procedury składowane Przygotowana dla potrzeb aplikacji baza danych składa się z trzech prostych tabel powiązanych relacjami. Dodatkowo zawiera procedurę składowaną, którą wykorzystamy w dalszej części szkolenia w ramach omawiania sposobu komunikowania się za bazą danych. Tabela Student zawiera informacje o uczniach ( dla zachowania prostoty obejmuje jedynie imię i nazwisko ucznia oraz jego identyfikator) Tabela Subject pełni analogiczna rolę w stosunku do informacji o przedmiotach (nazwa oraz identyfikator przedmiotu) Pomiędzy tabelą Student i Subject zachodzi relacja wiele-do-wielu z oceną ucznia. Jest ona opisywana data wystawienia oceny, jej wartością oraz skojarzeniem z uczniem i przedmiotem. Jako, że relacji wiele-do-wielu nie da się wprost zaimplementować w bazie danych, została ona zrealizowana jako osobna tabela StudetNote. Wspomniana wcześniej procedura składowana służy do wystawienia wskazanemu uczniowi określonej oceny z wybranego przedmiotu informatyka +

27 Agenda Architektura aplikacji korzystających z baz danych Jaką architekturę wybrać i kiedy? Na co zwrócić uwagę, żeby później nie pluć sobie w brodę? Co oferuje .NET Framework w zakresie dostępu do danych? Planowanie i implementacja warstwy dostępu do danych Metoda „na piechotę” Data Access Application Block (Enterprise Library) LINQ to SQL mało? ... krótki przegląd innych możliwości Podsumowanie i wnioski Celem tej części szkolenia jest zademonstrowanie sposobu korzystania z podstawowych klas służących do komunikowania się za bazą danych. Zaprezentowane zostaną typowe scenariusze, a także zaimplementujemy pierwszy wariant naszej warstwy dostępu do danych i sprawdzimy jego działanie. informatyka +

28 Metoda „na piechotę” informatyka +
Komunikacja z baza danych (typowy scenariusz): Utworzenie połączenia z bazą (SqlConnection) Utworzenie polecenia do wykonania (SqlCommand) Otwarcie połączenia Wykonanie polecenia (ExecuteReader(), ExecuteScalar(), ExecutenonQuery()) Przetworzenie wyników (iteracja po SqlDataReader) Zamknięcie połączenie Najprostszy scenariusz komunikacji z bazą danych składa się z 6 etapów Utworzenie obiektu SqlCommand i przekazanie mu ciągu definiującego połączenie z bazą (connection string) Utworzenie obiektu SqlCommand reprezentującego polecenie do wykonania. Może to być polecenie DML, DDL, DCL lub wywołanie procedury składowanej). Jeżeli to konieczne, należy do stworzonego obiektu dodać definicje parametrów wykonania polecenia. Otwarcie połączenia – wykonanie metody Open() obiektu SqlCommand Wykonanie polecenia za pośrednictwem obiektu SqlConnection skojarzonego z SqlCommand. Istnieją trzy warianty wykonania polecenia: ExecutenonQuery() – stosowane gdy nie spodziewamy się zwrotnie zbioru rekordów (recordset). ExecuteScalar() – stosowane gdy zwrotnie dostajemy zbiór rekordów zawierający jeden rekord z jedna kolumną. Upraszcza mechanizm „wyłuskania” zwróconej wartości ExecuteReader() – stosowane gdy spodziewamy się zwrotnie zbioru (lub zbiorów) rekordów. Metoda ta zwraca obiekt SqlDataReader, który można traktować jako prosty kursor „read and forward only”, czyli pozwalający na iterowanie po kolejnych rekordach ze zbioru zwróconego przez polecenie. Pozwala także na przejście do kolejnego zbioru rekordów (o ile polecenie spowodowało zwrócenie takowego). Przetworzenie wyników polega zwykle na przeiterowaniu po rekordach zwróconych w zbiorze wynikowym. Istotnym zagadnieniem jest zamknięcie połączenia z bazą, gdyż w przeciwnym przypadku można szybko doprowadzić do niepotrzebnego alokowania zasobów i utrzymywania niepotrzebnych już połączeń. informatyka +

29 Metoda „na piechotę” – ogólna koncepcja
Przykładowy kod realizujący scenariusz opisany na poprzednim slajdzie. Należy zaakcentować, że nie jest to dobry przykład, jak w praktyce wykonywać operacje na bazie!!! Ten kod nie uwzględnia możliwości wystąpienia błędu, a w takim przypadku połączenie z bazą może zostać otwarte. Celem tego kodu jest jedynie zilustrowanie realizacji kolejnych etapów scenariusza omówionego na poprzednim slajdzie. Kwestia sensownego przechowywania zawartości łańcucha połączenia i treści polecenia również nie jest tu istotna. W prawdziwych projektach tego typu informacje są przechowywane w plikach konfiguracyjnych aplikacji, często w formie zaszyfrowanej. Zaprezentowany kod będzie poprawnie działał, jeżeli nie wystąpią żadne nieprzewidziane sytuacje i nie nastąpi „wyrzucenie” wyjątku. Każdy wyjątek spowoduje, że połączenie z baza nie zostanie automatycznie zamknięte i będzie niepotrzebnie zużywać zasoby serwera. informatyka +

30 Metoda „na piechotę” – praktyczne rozwiązanie
W praktyce scenariusz opisany na poprzednich slajdach realizuje się w bezpieczniejszy sposób - zastosowanie konstrukcji „using” gwarantuje, że w momencie wyjścia z bloku kodu: using (Typ x = new Typ()) { … } Zostanie wywołana metoda Dispose() obiektu „x”, która zgodnie z przeznaczeniem powinna zawierać kod zwalniający zasoby używane przez obiekt „x”. W naszym przypadku będzie to zamknięcie połączenia z bazą. Metoda ta zostanie wywołana ZAWSZE. Nawet gdy wystąpi nieoczekiwany wyjątek. Wewnętrznie jest to realizowane poprzez zamianę bloku using {…} na blok try{…} finally{…}. Przy okazji warto zwrócić uwagę słuchaczy na problem zasobów niezarządzalnych (połączenia z bazą, uchwyty do plików i okien itp.) oraz na interfejs IDisposable, który jest przyjętym sposobem za zapewnienie bezpiecznego zwalniania zasobów niezarządzalnych. Można także przypomnieć pojęcia stosu (stack) i sterty(heap) aby ułatwić zrozumienie zagadnienia. Wypadałoby jeszcze wspomnieć o kwestii zarządzania połączeniem z bazą danych. Tego typu zasoby są uznawane za dość kosztowne, więc należy zwrócić szczególną uwagę na sposób posługiwania się nimi. Mamy to do czynienia z dwoma skrajnościami: Utworzenie połączenia, otwarcie go i trzymanie w tym stanie w trakcie działania aplikacji. Tworzenie połączenia za każdym razem gdy chcemy przesłać polecenie do bazy i niezwłoczne zamykanie go zaraz po odebraniu wyników. Często uznaje się, że ciągłe otwieranie i zamykanie połączeń ma negatywny wpływ na wydajność ze względu na to, że utworzenie i nawiązanie połączenia z bazą jest dość kosztowne. Na szczęście SQL Server posiada mechanizm (Connection Pooling) , który pozwala zapomnieć o problemach z wydajnością. Zamykane połączenie nie jest tak naprawdę niszczone, tylko trafia do specjalnej puli, z której będzie ponownie pobrane i użyte w razie potrzeby. Dzięki temu można przyjąć (dotyczy to szczególnie aplikacji webowych), że połączenie można śmiało tworzyć wyłącznie na czas wykonania polecenia. Do tego właśnie służy zaprezentowany kod. informatyka +

31 Metoda „na piechotę” – zwrócenie SqlDataReadera
Przykładowy kod realizujący scenariusz opisany na poprzednich slajdach. Jako, że celem jest zwrócenie obiektu SqlDataReader do wykorzystania przez inne obiekty – nie można zastosować konstrukcji „using” do zapewnienia bezpiecznego zamknięcia połączenia z bazą. Zastosowanie „using” powodowałoby, że SqlDataReader stałby się bezużyteczny, gdyż do pobierania kolejnych rekordów wymaga on otwartego połączenia z bazą. Jest to istotna cecha obiektu DataReader – potrzebuje on otwartego połączenia z bazą. Aby móc bezpiecznie zamknąć połączenie po wykorzystaniu SqldataReader-a w innej metodzie, należy skorzystać z parametru CommandBehavior.CloseConnection, który spowoduje automatyczne zamknięcie połączenia w momencie wywołania metody Close() lub Dispose() SqlDataReadera. Parametr CommandBehavior.CloseConnection pozwala na zwrócenie obiektu SqlDataReader, który automatycznie zamknie połączenie z bazą gdy zostanie wykonana jego metoda Close(). informatyka +

32 Metoda „na piechotę” – korzystanie z parametrów
zamiast parametrów można po prostu „skleić” fragmenty polecenia wplatając w odpowiednie miejsca wartości parametrów. Jest to jednak NIEBEZPIECZNE i może być wykorzystane do przeprowadzenia ataku typu SQL Injection korzystanie z parametrów eliminuje większość takich zagrożeń Często do polecenia wysyłanego do bazy trzeba wstawić wartości przekazane przez użytkownika. Można to zrealizować poprzez zbudowanie całego polecenia z fragmentów stałych przeplatanych wartościami podanymi przez użytkownika. Budowanie takiego polecenia wygląda na najprostszą metodę, lecz stanowi spore zagrożenie. Po pierwsze przy bardziej skomplikowanych poleceniach łatwo można popełnić błąd, który spowoduje, że serwer baz danych nie będzie potrafił wykonać polecenia z powodu błędnej składni (niedomknięte apostrofy itp.). Także modyfikowanie zapytania stworzonego w ten sposób nastręcza wielu problemów. Większym zagrożeniem są jednak ataki typu SQL Injection. Polegają one z grubsza na tym, że użytkownik aplikacji podaje specjalnie sformatowane wartości, które po wkomponowaniu w polecenie modyfikują jego działanie. Przykładowo: Aplikacja prosi użytkownika o podanie loginu i hasła. tworzone jest zapytanie: string polecenie= ‘select * from uzytkownicy where login=” ‘ + login + ’ ” and haslo = ” ‘+ haslo +’ ” ‘ Dla podanych przez uzytkownika danych: login=janek, haslo= qaz123 wygenerowane polecenie będzie miało postać: select * from uzytkownicy where login=” janek ” and haslo = ”qaz123 ” I wszystko będzie ok. Ale, jeżeli użytkowniok jako login poda: ” or 1= a jako haslo dowolna inna wartość, np. akuku To: select * from uzytkownicy where login=”” or 1=1 -- and haslo = ”qaz123 ” Efekt wykonania jest zdecydowanie niepożądany… informatyka +

33 Metoda „na piechotę” – korzystanie z parametrów
Najbardziej eleganckim rozwiązaniem jest korzystanie z procedur składowanych. Pozwala to na uproszczenie tworzonego kodu oraz na „uodpornienie” go na zmiany w bazie (np. zmiana postaci zapytania). W takich przypadkach kod pozostaje niezmienny do momentu, w którym zmienia się parametry wywołania procedury składowanej. Pozwala to dodać dodatkową warstwę abstrakcji odcinającą kod dostępu do danych od szczegółów implementacyjnych samej bazy. Dodatkowym efektem jest otrzymanie aplikacji, w której można część modyfikacji wprowadzić bez dokonywania jakichkolwiek zmian w kodzie – zmieniając jedynie kod procedur składowanych w bazie. Z drugiej strony – rosnąca ilość logiki zaszytej w bazie danych w postaci skomplikowanego kodu SQL powoduje wzrost nakładów pracy potrzebnych na jego utrzymanie i weryfikowanie poprawności działania po naniesieniu modyfikacji. najwygodniej jest skorzystać z procedury składowanej można używać parametrów wejściowych, wyjściowych oraz korzystać z wartości zwracanej (return value) informatyka +

34 Metoda „na piechotę” – SchoolController
Sposób korzystania z warstwy dostępu dodanych został zaimplementowany w klasie SchoolController. Zawiera ona metody zwracające encje biznesowe lub ich kolekcje (listy) oraz pozwalające na przekazanie parametrów do warstwy dostępu do danych. Komunikacja z warstwą dostępu do danych odbywa się za pośrednictwem pola „service” typu IStudentNotesDB. W konstruktorze klasy SchoolController do tego pola przypisywana jest referencja do odpowiedniego obiektu implementującego interfejs IStudentNotesDB. Na pierwszy ogień idzie klasa StudentnotesDBSimple, której metody zaimplementowane są metodą „na piechotę”. Takie rozwiązanie jest bardzo proste i umożliwia późniejsze przełączenie się na korzystanie z zupełnie innej klasy realizującej dostęp do danych. Istnieją bardziej eleganckie sposoby „przełączania” niż komentowanie/odkomentowanie linijki kodu, ale nie są one tematem szkolenia. Warto tu jedynie wspomnieć o wzorcach projektowych takich jak Abstract Factory czy Dependency Injection. informatyka +

35 Metoda „na piechotę” – aplikacja desktopowa
Przy tym slajdzie należy zademonstrować i pokrótce omówić implementację aplikacji desktopowej w Visual Studio. Należy także zademonstrować w jaki sposób korzysta ona z klasy SchoolController. Istotą omówienia powinno być wskazanie, że umieszczany w aplikacji kod realizujący operacje biznesowe (a przez nie także bazodanowe) jest skrajnie prosty i ogranicza się do utworzenia obiektu i skorzystania z jego metody. Cała reszta kodu aplikacji dotyczy wyłącznie tego jak ma wyglądać i zachowywać się sama aplikacja i jej kontrolki umieszczone na formatce. Żeby uniknąć tworzenia obiektu klasy SchoolColntroller w każdej metodzie od nowa, dodano prywatne pole w klasie formatki i zainicjowano je wstępnie nową instancją klasy SchoolController. Ilość kodu niezwiązanego z logiką aplikacji (obsługa zdarzeń, sterowanie zachowaniem kontrolek itp.) jest minimalna i sprowadza się do wywołania metody obiektu controller. Aplikacja nie ma i nie musi mieć żadnych informacji na temat sposobu uzyskania dostępu do bazy danych. informatyka +

36 Metoda „na piechotę” - podsumowanie
Kod budowany w oparciu o stałe szablony Łatwo popełniać błędy Bez korzystania z procedur składowanych – silna zależność od struktury bazy i zapytań Wielokrotne powtarzanie tego samego kodu różniącego się niewielkimi fragmentami Korzystanie z tego sposobu niechybnie prowadzi do wniosku, że można by to nieco uprościć (poprzez tworzenie uogólnionych metod) Już po napisaniu kilku metod operujących na danych z bazy programista zauważa, że pisze wielokrotnie prawie identyczne fragmenty kodu, które różnią się jedynie treścią przekazywanych poleceń bądź listą parametrów. Prowadzi to do podjęcia decyzji o stworzeniu pa przyszłość bardziej uogólnionych metod, które będzie można wywoływać podający tylko informacje specyficzne dla konkretnego polecenia. Pozwoli to na unikanie błędów i stworzenie spójnego mechanizmu komunikacji z bazą. informatyka +

37 Metoda „na piechotę” – podsumowanie cd.
NIE TRZEBA JEDNAK TEGO ROBIĆ! Wielu ludzi wpadło na ten pomysł wcześniej i często udostępniają swoje wynalazki innym. Najlepiej jednak korzystać ze sprawdzonych, przemyślanych i dobrze udokumentowanych rozwiązań – jeżeli trafimy na problem, to istnieje spora szansa, że już ktoś się z nim spotkał i znalazł rozwiązanie. Oczywiście rzadko kiedy trzeba będzie tworzyć takie rozwiązania samemu. W Internecie aż roi się od gotowych rozwiązań oferujących bardzo zróżnicowaną funkcjonalność. Warto poświęcić nieco czasu i rozeznać się w co bardziej popularnych projektach i ocenić ich przydatność w realizowaniu własnych. Istotną rzeczą jest inwestowanie czasu w już sprawdzone rozwiązania, najlepiej szeroko stosowane i dobrze udokumentowane i zweryfikowane empirycznie przez wielu ludzi. Pozwoli to na uniknięcie trudnych chwil w projekcie, gdy okazuje się nagle, że przyjęte rozwiązanie zupełnie nie radzi sobie z zadaniem, które trzeba zrealizować w ramach projektu. informatyka +

38 Metoda „na piechotę” – podsumowanie cd.
Nie korzystaliśmy z klas DataSet, SqlDataAdapter, TableAdapter – są to rozwiązania opisane w każdej książce i najprostszym tutorialu dotyczącym dostępu do danych w .NET. Pozornie są one wygodne i szybko da się „wyklikać” w ten sposób gotowy mechanizm, ale szybko okazuje się, że jest on niezbyt wydajny, nadaje się tylko do typowych rozwiązań i trudno go modyfikować. Celowo pomijamy korzystanie z TableAdapter-ów, DataSet-ów itp. Posługiwanie się nimi jest dokładnie opisane w tak wielu miejscach, że nie ma sensu omawiać tego w ramach tego szkolenia. To rozwiązanie można stosować w praktyce, jednak należy zdawać sobie sprawę, że posiada dość złożoną funkcjonalność, a co za tym idzie spory narzut jeśli chodzi o wydajność i zapotrzebowanie na zasoby. Przy każdym projekcie trzeba ocenić na ile wygodnie byłoby skorzystać z tego typu mechanizmów i czy potrzeba aż tak wyrafinowanych mechanizmów. Często widuje się w projektach korzystanie z obiektu DataSet jedynie w celu podpięcia listy opcji do listy rozwijalnej… można to śmiało porównać do strzelania do muchy z pistoletu:) informatyka +

39 Agenda Architektura aplikacji korzystających z baz danych Jaką architekturę wybrać i kiedy? Na co zwrócić uwagę, żeby później nie pluć sobie w brodę? Co oferuje .NET Framework w zakresie dostępu do danych? Planowanie i implementacja warstwy dostępu do danych Metoda „na piechotę” Data Access Application Block (Enterprise Library) LINQ to SQL mało? ... krótki przegląd innych możliwości Podsumowanie i wnioski Celem tej części szkolenia jest zademonstrowanie w działaniu Data Access Application Block. DAAB jest przykładem efektu prac prowadzonych w zakresie uogólnienia i uproszczenia korzystania ze standardowych mechanizmów dostępu do danych. Jest to rozwiązanie powstałe i rozwijane przy udziale pracowników Microsoft oraz społeczności skupionej wokół .NET. informatyka +

40 DAAB – koncepcja informatyka + Źródło:Dokumentacja DAAB
Podstawowym założeniem DAAB jest przeniesienie pracy z bazą danych na wyższy poziom abstrakcji. Już tworząc kod dostępu do danych nie musimy się martwić konfigurowaniem połączenia. Skupiamy się na poleceniach, które chcemy wykonać i na postaci efektu ich wykonania (rodzaj zwróconego obiektu itp.) Diagram zaczerpnięty z dokumentacji DAAB obrazuje sposób korzystania z DAAB: kluczowym obiektem jest obiekt typu Database, którego instancji nie tworzy sam programista, tylko specjalna klasa DatabaseFactory. To ona jest odpowiedzialna za odnalezienie w pliku konfiguracyjnym aplikacji informacji o sposobie łączenia się z bazą danych oraz o rodzaju bazy danych (SQL Server, Oracle itp..) obiekt typu Database udostępnia cały szereg metod służących do przekazywania poleceń do bazy danych i odbierania wyników w razie potrzeby (bardziej wyrafinowane operacje na bazie: organizowanie transakcji, ustawianie parametrów połączenia (timeout) i polecenia) można uzyskać dostęp do używanych wewnętrznie przez obiekt typu Database obiektów DbConnection, DbCommand. dodatkowo DAAB posiada wbudowane mechanizmy powodujące wzrost wydajności (np.: cache dla obiektów SqlParameter wykorzystywanych przy wywoływaniu procedur i polecen z parametrami) Źródło:Dokumentacja DAAB informatyka +

41 DAAB – tworzenie kodu dostępu do danych
Typowy scenariusz komunikacji z bazą: Utworzenie instancji klasy Database Wywołanie metody utworzonej instancji Cechy rozwiązania: Nie trzeba martwic się o otwieranie i zamykanie połączeń Nie trzeba martwić się o definiowanie parametrów (czasem trzeba…) Zwięzły i czytelny kod Odporność na błędy – wbudowana obsługa Szczególnie wygodne rozwiązanie przy korzystaniu z procedur składowanych Kod, który trzeba napisać, żeby wykonać polecenie bazodanowe przy użyciu DAAB jest skrajnie prosty i w sporej części przypadków składa się z jednej linijki. Programista nie musi pilnować procesu nawiązywania połączenia z bazą oraz jego zamykania a także obsługi błędów z tym związanych. Nie musi także definiować parametrów poleceń – wystarczy przekazanie kolejnych wartości parametrów jako argumentów wywołania metody obiektu klasy Database. DAAB przed wykonaniem polecenia sam pobierze z bazy informacje na temat parametrów konkretnej procedury, stworzy odpowiednie obiekty SqlParameter i przypisze im wartości. Do tego utworzone obiekty zostaną umieszczone w cache’u i przy kolejnyc wywołaniach tej procedury będą gotowe do użycia (wzrost wydajności) W tworzonym kodzie nie ma ŻADNYCH informacji o docelowej bazie danych i jej typie – zawiera on jedynie informacje na temat poleceń, które trzeba wykonać. Raz napisany i skompilowany kod może być wykorzystywany do komunikacji z dowolną bazą danych w dowolnej aplikacji. To właśnie aplikacja dostarcza informacji na temat typu i lokalizacji serwera baz danych z którym będzie się komunikować. informatyka +

42 DAAB – tworzenie kodu dostępu do danych cd.
Przykładowy kod programu: Na tym przykładzie łatwo zauważyć jak bardzo zmniejsza się ilość tworzonego kodu. Dodatkowo programista koncentruje się na samym poleceniu i ewentualnych parametrach jego wywołania. Cała reszta jest załatwiana na poziomie konfigurowania aplikacji. informatyka +

43 DAAB – konfigurowanie aplikacji
DAAB można konfigurować za pomocą wygodnego narzędzia Otwiera się w nim plik konfiguracyjny aplikacji Po „wyklikaniu” konfiguracji narzędzie tworzy odpowiednie wpisy w pliku konfiguracyjnym aplikacji na podstawie tych wpisów klasa DatabaseFactory tworzy odpowiednie obiekty i konfiguruje je do komunikacji z właściwą bazą Przy tym slajdzie należy zaprezentować omawiane zagadnienie w kodzie aplikacji w Visual Studio. Najistotniejsza jest kwestia odseparowania definicji operacji wykonywanych na bazie od konfiguracji typu bazy i rodzaju połączenia. Pozwala to na tworzenie kodu, który może być wykorzystany bez żadnych zmian do komunikacji z różnymi bazami danych. informatyka +

44 DAAB – konfigurowanie aplikacji cd.
Elementy konfigurowania Narzędzie Enterprise Library Configuration służy do edycji pliku konfiguracyjnego aplikacji .NET (webowej lub desktopowej). Dzięki niemu możemy łatwo skonfigurować nie tylko DAAB ale także każdy inny blok wchodzący w skład Enterprise Library. Efektem zapisania zmian jest dodanie nowych sekcji w pliku konfiguracyjnym aplikacji, które to sekcje odpowiadają poszczególnym blokom Enterprise Library. informatyka +

45 DAAB – konfigurowanie aplikacji cd.
Wygenerowany dokument XML Ten slajd przedstawia postać pliku konfiguracyjnego aplikacji po zapisaniu zmian w Enterprise Library Configuration. Przy tej okazji warto zademonstrować cały proces konfigurowania DAAB: Otworzyć lub utworzyć plik konfiguracyjny dla aplikacji – pokazując jego zawartość xml. Otworzyć ten sam plik w Enterprise Library Configuration – pokazać jak wygląda w tym narzędziu Dodać sekcję konfiguracyjną dla DAAB i zdefiniować łańcuch połączenia Zapisać zmiany Otworzyć ten sam plik ponownie pokazując jego zawartość xml. Oczywiście nie trzeba korzystać z Enterprise Library Configuration, można wszystkie zmiany nanosić od razu w pliku konfiguracyjnym. informatyka +

46 DAAB – zmiany w aplikacji
Żeby skorzystać z nowej implementacji warstwy dostępu do danych wystarczy: dodać do aplikacji referencję do projektu zawierającego kod dostępu do danych zmodyfikować plik konfiguracyjny aplikacji za pomocą narzędzia Enterprise Library Configuration W klasie SchoolController zmodyfikować konstruktor Dzięki przyjętej architekturze, przełączenie aplikacji na korzystanie z innej biblioteki dostępu do danych jest bardzo proste. Klasy z nowej biblioteki implementują ten sam interfejs IStudentNotesDB i dzięki temu jedyna zmiana w kodzie aplikacji polega na zmodyfikowaniu konstruktora klasy SchoolController tak, aby tworzona w nim była instancja klasy z nowej biblioteki. Pozostałe zmiany są zlokalizowane w pliku konfiguracyjnym i mogą być realizowane za pomocą narzędzia Enterprise Library Configuration. informatyka +

47 DAAB – podsumowanie informatyka + Znaczne uproszczenie kodu
Poprawa wydajności Spójna obsługa błędów Wygodna konfiguracja Bogata dokumentacja i wsparcie Korzystanie z DAAB pozwala na zaoszczędzenie sporej ilości czasu oraz na tworzenie spójnego i przewidywalnego kodu Biblioteka ta jest ciągle rozwijana i udoskonalana a także stosowana z powodzeniem w praktyce w wielu organizacjach Przy tworzeniu aplikacji warto się także zainteresować pozostałą częścią Enterprise Library, która zawiera jeszcze kilka bloków, które można wykorzystać do budowy aplikacji. informatyka +

48 Agenda Architektura aplikacji korzystających z baz danych Jaką architekturę wybrać i kiedy? Na co zwrócić uwagę, żeby później nie pluć sobie w brodę? Co oferuje .NET Framework w zakresie dostępu do danych? Planowanie i implementacja warstwy dostępu do danych Metoda „na piechotę” Data Access Application Block (Enterprise Library) LINQ to SQL mało? ... krótki przegląd innych możliwości Podsumowanie i wnioski Celem tej części szkolenia jest zademonstrowanie w działaniu LINQ To SQL. Jest to nowa koncepcja programowania zapytań poprzez zestaw konstrukcji wbudowanych bezpośrednio w język programowania. Te konstrukcje są następnie „tłumaczone” na SQL i wysyłane do odpowiedniej bazy i wykonywane. informatyka +

49 LINQ to SQL – wprowadzenie
LINQ – Language Integrated Query Język zapytań zostaje wbudowany w języki programowania Programista nie martwi się szczegółami i niezależnie od źródła danych używa tej samej składni LINQ w celu budowania zapytań i manipulowania danymi Istnieje kilka wariantów LINQ przeznaczonych do współpracy z różnymi źródłami danych LINQ to SQL współpracuje TYLKO z SQL Server 2005 lub 2008 Przy komunikowaniu się z bazą danych zwykle występował problem budowania zapytań. Niezależnie od języka programowania, w którym tworzona była aplikacja, język zapytań do bazy (czy innego źródła danych) był zawsze odrębny i stanowił „wyspy” w kodzie aplikacji. To zjawisko dało się zauważyć w obu zaprezentowanych do tej pory przykładach w postaci poleceń SQL budowanych w mniej lub bardziej złożony sposób. LINQ, jak sama nazwa wskazuje, stanowi odejście od tej koncepcji i wprowadza język budowania zapytań zintegrowany z językiem programowania. LINQ występuje w kilku wariantach pozwalających na korzystanie z różnych źródeł danych (relacyjnych baz danych, XML, Datasetów, innych obiektów). W ramach szkolenia skorzystamy z LINQ to SQL – wariantu przeznaczonego do współpracy z SQL Server 2005 i 2008. LINQ to SQL można sklasyfikować jako O/RM (Object/Relational Mapping). informatyka +

50 LINQ to SQL – architektura
Ten slajd ilustruje osadzenie koncepcji LINQ w .NET. W ramach szkolenia nie zajmujemy się samym LINQ jako takim, tylko jednym z jego wariantów – LINQ To SQL – przeznaczonym do współpracy z SQL Serverem informatyka +

51 LINQ to SQL – korzystanie
Podstawą przy pracy z LINQ to SQL jest stworzenie modelu: Głównym elementem biblioteki stworzonej za pomocą LINQ to SQL jest model. Tworzy się go poprzez dodanie do projektu szablonu „LINQ to SQL Classes. Dalsza praca z modelem polega na przeciąganiu i upuszczaniu obiektów z bazy danych (z narzędzia Server Explorer/Data connections), co powoduje generowanie w tle potrzebnych klas. Modyfikacja modelu zwykle ogranicza się do dopasowania nazw wygenerowanych typów, uzupełnienia ich o dodatkowe metody i właściwości oraz skonfigurowania ich zachowania przy komunikacji z bazą danych. informatyka +

52 LINQ to SQL – korzystanie cd
Tworzenie może odbywać się „ręcznie” lub za pomocą wygodnego narzędzia (designera) Praca z designerem sprowadza się do przeciągania i upuszczania obiektów z bazy (tabel, widoków, procedur składowanych i funkcji). Na tej podstawie zostaje wygenerowany kod klas odpowiadających tym obiektom Łatwo można modyfikować i rozszerzać zachowanie wygenerowanych klas Nie trzeba w kodzie aplikacji umieszczać żadnego kodu SQL! Nie trzeba tworzyć samodzielnie encji biznesowych (Student, Note, Subject…) Istotną rzeczą jest fakt, że po wygenerowaniu modelu można tworzyć dowolnie skomplikowane zapytania, które LINQ to SQL automatycznie „przetłumaczy” na SQL i wykona. Do tego programista jest zwolniony z tworzenia klas encji biznesowych (które musieliśmy tworzyć ręcznie w poprzednich przykładach) Wygenerowany już model łatwo można modyfikować, żeby nadążyć za zmianami w bazie danych. Istnieją także narzędzia automatyzujące generowanie modelu – np. SQL Metal, który potrafi wygenerować model dla wskazanej bazy danych. informatyka +

53 LINQ to SQL – praca z modelem
Przy tym slajdzie należy zaprezentować proces tworzenia modelu ( od zdefiniowania połączenia z bazą po modyfikowanie wygenerowanych klas). Warto wspomnieć, że przy korzystaniu w nazewnictwie encji z nazw angielskich w liczbie pojedynczej, narzędzie automatycznie nazwie niektóre właściwości generowanych klas. Np. jeżeli na modelu będą dwie tabele Student i StudentNote połączone relacją, to wygenerowana klasa Student będzie miała właściwość StudentNotes, której nazwa zostanie automatycznie wygenerowana. Należy zaakcentować, że można korzystać nie tylko z tabel, ale też z widoków, funkcji i procedur składowanych. Pozwala to zwiększyć wpływ programisty na kod SQL, który będzie wykonywany w bazie danych. W przypadku korzystania tylko z tabel i widoków programista nie musi w ogóle tworzyć kodu SQL ani w aplikacji ani w bazie. informatyka +

54 LINQ to SQL – praca z modelem
Model utworzony z trzech tabel i jednej procedury składowanej Przy tym slajdzie należy zaprezentować w Visual Studio właściwości wygenerowanych klas i możliwości konfigurowania ich zachowania. Istotne jest wskazanie silnego powiązania z SQL Serverem, chociażby przez korzystanie z jego typów danych we właściwościach klas modelu. informatyka +

55 LINQ to SQL – Model N modelu można także tworzyć relacje pomiędzy encjami. Nie muszą one odpowiadać kluczom obcym w bazie. Można je budować w sposób dowolny. Klucze obce są natomiast podstawą do automatycznego wygenerowania relacji. Efektem istnienia relacji pomiędzy encjami jest pojawienie się w nich dodatkowej właściwości zawierającej referencję do encji znajdującej się na drugim końcu relacji. Przykładowo klasa Student będzie miała właściwość StudentNotes prowadzącą do listy ocen studenta, a każda ocena będzie miała (zależnie od tego czy sobie tego życzymy) referencję do encji Studenta, do którego ocena należy. Relacje na modelu odpowiadają kluczom obcym i powodują tworzenie dodatkowych właściwości w wygenerowanych klasach. Np. klasa Student będzie miała właściwość StudentNotes informatyka +

56 LINQ to SQL – DataContext
Efekt pracy z modelem – klasa DataContext Zawiera właściwości odpowiadające tabelom i widokom oraz metody odpowiadające procedurom i funkcjom Utworzenie modelu daje efekt w postaci wygenerowanych klas. Podstawową jest klasa DataContext, której instancję tworzy się zawsze, gdy chce się skorzystać z danych. Należy zaznaczyć, że zawiera ona wiele dodatkowych metod, właściwości i zdarzeń pozwalających na operowanie na danych oraz śledzenie zmian. informatyka +

57 LINQ to SQL – Encje (tabele i widoki)
Automatycznie wygenerowane encje odpowiadają klasom budowanym ręcznie w poprzednich przykładach. Dodatkowo w tym przypadku klasy te mają wiele dodatkowych metod i zdarzeń pozwalających na wygodne operowanie nimi i śledzenie zmian. Większości z nich w standardowych przypadkach nie trzeba używać. Są przeznaczone do bardziej zaawansowanych scenariuszy i dają ogromne możliwości sterowania procesem manipulowania danymi informatyka +

58 informatyka + LINQ to SQL – klasa (odpowiednik IStudentNotesDB)
Aby ułatwić tworzenie aplikacji, do projektu dodana została jeszcze jedna klasa – StudentNotesDBLINQ. Zawiera ona metody odpowiadające wymaganiom stawianym aplikacji. Jest to odpowiednik Interfejsu IStudentNotesDB. Tym razem jednak nie korzystamy z klas biznesowych zdefiniowanych w projekcie DzienniczekUczniaCore, gdyż LINQ to SQL wygenerowało nam gotowe encje biznesowe. Klasa StudentNotesDBLINQ pełni więc bardziej rolę klasy SchoolController, i co ważne, uniknęliśmy ręcznego tworzenia encji biznesowych. Należy zwrócić także uwagę na prostotę składni LINQ, stosowanie wyrażeń lambda oraz na fakt stosowania interfejsu IQueryable<T>. Trzeba wyjaśnić, że polecenie jest faktycznie wysyłane do bay i wykonywane dopiero po wywołaniu niektórych metod interfejsu Iqueryable<T>. Pozwala to zwrócić do aplikacji obiekt (reprezentujący np rekordów w tabeli), którym można manipulować (sortować, filtrować itp.) i dopiero po wykonaniu metody np. ToList() jest budowane polecenie select, które wybiera z bazy potrzebne dane. informatyka +

59 LINQ to SQL – korzystanie w aplikacji
Z punktu widzenia kodu aplikacji korzystanie z przygotowanego kodu jest skrajnie proste. Trzeba stworzyć instancję klasy StudentNotesDBLINQ, a następnie korzystać z jej metod. Zaakcentować należy moment skorzystania z metod OrderBy() i ToList(). Poerwsza z nich powoduje, że wyniki będą posortowane, druga natomiast „daje sygnał”, że LINQ to SQL powinno wygenerować polecenie, które zwróci potrzebne dane. Nie odbywa się to w ten sposób, że LINQ pobiera wszystkie dane z tabeli w bazie i potem dopiero je sortuje! Istotą LINQ to SQL jest tzw „lazy loading” polegające na tym, że wartości są pobierane dopiero, gdy są potrzebne. Można zademonstrować słuchaczom jak to działa z wykorzystaniem SQL Profilera – uruchomić przykładową aplikację webową i pokazać w którym momencie polecenie jest wysyłane do bazy i jaka jest jego postać. informatyka +

60 LINQ to SQL – podsumowanie
Korzystanie z LINQ to SQL pozwala uniknąć pisania sporej ilości kodu ( jest generowany automatycznie) Dotyczy to również pisania poleceń SQL Poprzez korzystanie z widoków, wyzwalaczy oraz funkcji i procedur składowanych można mieć w szczególnych przypadkach wpływ na postać poleceń wykonywanych przez bazę danych LINQ to SQL znakomicie upraszcza i przyspiesza proces tworzenia kodu organizującego dostęp do bazy danych. Korzysta z dobrych praktyk i jest zaprojektowane tak, aby zapewnić wysoką wydajność. Dzięki silnej kontroli typów programiści mogą uniknąć popełniania błędów, które ujawnią się dopiero po uruchomieniu aplikacji. Przykładowo przy korzystaniu z SqlDataReadera, jeżeli popełnimy błąd literowy w nazwie kolumny lub wykonamy rzutowanie na niewłaściwy typ – efektem będzie powstanie wyjątku w trakcie działania aplikacji. W przypadku LINQ błąd pojawi się już na etapie kompilacji. LINQ to SQL jest z powodzeniem stosowane przy tworzeniu prostych projektów RAD (Rapid Application Development) dzięki swojej prostocie. informatyka +

61 LINQ to SQL – podsumowanie cd.
Można na tę postać wpływać także przez konfigurowanie właściwości klas modelu LINQ to SQL zapewnia wydajność na akceptowalnym poziomie i pozwala uniknąć wielu typowych błędów przy tworzeniu zapytań SQL. Zapewnia przyspieszenie procesu tworzenia kodu Działa tylko z SQL Server 2005 i 2008 :( LINQ to SQL sprawdza się w większości prostych systemów. Ograniczenie do SQL Servera 2005 i 2008 zwykle nie powoduje problemów. Jeżeli natomiast trzeba łączyć się z innym serwerem baz danych lub chce operować się na bardziej abstrakcyjnym modelu, to można skorzystać ze „starszego brata” LINQ To SQL – ADO.NET Entity Framework. Jest on znaczniej bardziej skomplikowany ale po nabraniu wprawy pozwala na równie szybkie tworzenie aplikacji informatyka +

62 Agenda Architektura aplikacji korzystających z baz danych Jaką architekturę wybrać i kiedy? Na co zwrócić uwagę, żeby później nie pluć sobie w brodę? Co oferuje .NET Framework w zakresie dostępu do danych? Planowanie i implementacja warstwy dostępu do danych Metoda „na piechotę” Data Access Application Block (Enterprise Library) LINQ to SQL mało? ... krótki przegląd innych możliwości Podsumowanie i wnioski informatyka +

63 Inne rozwiązania informatyka + Subsonic (http://subsonicproject.com )
nHibernate ( ) ADO.NET Entity Framework ( ) W Internecie można znaleźć wiele rozwiązań pozwalających na organizowanie dostępu do danych. Są tam rozwiązania bardzo proste, ale nie brak też bardzo rozbudowanych i skomplikowanych. Każde z nich ma grupę swoich zwolenników jak i przeciwników, a Internet jest pełen informacji na temat tego jak fajne/nie fajne jest konkretne rozwiązanie. Przy podejmowaniu decyzji o zastosowaniu takiego czy innego rozwiązania trzeba brać pod uwagę wiele czynników. Najważniejsze z punktu widzenia programisty są łatwość nauczenia się danego rozwiązania oraz dostępność dokumentacji i szeroko rozumianego wsparcia. Z punktu widzenia projektanta czy architekta brane pod uwagę są inne cechy – m.in. skalowalność, koszty, to czy projekt jest nadal rozwijany itd.. informatyka +

64 Agenda Architektura aplikacji korzystających z baz danych Jaką architekturę wybrać i kiedy? Na co zwrócić uwagę, żeby później nie pluć sobie w brodę? Co oferuje .NET Framework w zakresie dostępu do danych? Planowanie i implementacja warstwy dostępu do danych Metoda „na piechotę” Data Access Application Block (Enterprise Library) LINQ to SQL mało? ... krótki przegląd innych możliwości Podsumowanie i wnioski informatyka +

65 Podsumowanie informatyka +
Dokonaliśmy bardzo krótkiego i pobieżnego przeglądu technik organizowania dostępu do danych. Zaznaczyliśmy ich charakterystyczne cechy i różnice w koncepcjach Sprawdziliśmy w praktyce ich działanie Wymyślanie/korzystanie z rozwiązań dostępu do danych nie jest celem w samym sobie! W Internecie można znaleźć wiele rozwiązań pozwalających na organizowanie dostępu do danych. Są tam rozwiązania bardzo proste, ale nie brak też bardzo rozbudowanych i skomplikowanych. Każde z nich ma grupę swoich zwolenników jak i przeciwników, a Internet jest pełen informacji na temat tego jak fajne/nie fajne jest konkretne rozwiązanie. Przy podejmowaniu decyzji o zastosowaniu takiego czy innego rozwiązania trzeba brać pod uwagę wiele czynników. Najważniejsze z punktu widzenia programisty są łatwość nauczenia się danego rozwiązania oraz dostępność dokumentacji i szeroko rozumianego wsparcia. Z punktu widzenia projektanta czy architekta brane pod uwagę są inne cechy – m.in. skalowalność, koszty, to czy projekt jest nadal rozwijany itd.. informatyka +

66 Podsumowanie cd. informatyka +
Warstwa dostępu do danych jest tylko jednym z „klocków” wchodzących w skład aplikacji Ważne jest, żeby zdawać sobie sprawę z konsekwencji nieprzyłożenia właściwej wagi do sensownego zaplanowania architektury aplikacji Problemy pojawiają się nie przy tworzeniu, ale przy rozwijaniu i modyfikowaniu aplikacji. Właściwe podejście pozwala uniknąć tych problemów Warto sporo czytać na temat dobrych praktyk dotyczących planowania i tworzenia aplikacji W Internecie można znaleźć wiele rozwiązań pozwalających na organizowanie dostępu do danych. Są tam rozwiązania bardzo proste, ale nie brak też bardzo rozbudowanych i skomplikowanych. Każde z nich ma grupę swoich zwolenników jak i przeciwników, a Internet jest pełen informacji na temat tego jak fajne/nie fajne jest konkretne rozwiązanie. Przy podejmowaniu decyzji o zastosowaniu takiego czy innego rozwiązania trzeba brać pod uwagę wiele czynników. Najważniejsze z punktu widzenia programisty są łatwość nauczenia się danego rozwiązania oraz dostępność dokumentacji i szeroko rozumianego wsparcia. Z punktu widzenia projektanta czy architekta brane pod uwagę są inne cechy – m.in. skalowalność, koszty, to czy projekt jest nadal rozwijany itd.. informatyka +

67 Koniec Dziękuję za uwagę. …jakieś pytania? informatyka +

68