Obiekty wchodzą w relacje

Linq i ADO .Net 3.0 EDM to technologie mapowania obiektowo-relacyjnego dla platformy .Net, które zasadniczo ułatwiajątworzenie aplikacji biznesowych.

Linq i ADO .Net 3.0 EDM to technologie mapowania obiektowo-relacyjnego dla platformy .Net, które zasadniczo ułatwiajątworzenie aplikacji biznesowych.

Jeszcze kilka lat temu aplikacje korzystały w przeważającej mierze z danych udostępnianych przez relacyjne bazy danych. Obecnie mamy do czynienia z rosnącą różnorodnością źródeł danych, do których sięga aplikacja. Oprócz baz danych są to usługi Web, dane z modułów integracyjnych (w różnej postaci), dane hierarchiczne (nie tylko XML), a także foldery w systemach pocztowych czy wręcz pliki na dysku.

Nierelacyjne typy danych mają zazwyczaj własne pojemniki dysponujące własnymi mechanizmami kwerend. Dobrym przykładem może tu być XML i Xquery. Dane nierelacyjne można próbować sprowadzić do postaci relacyjnej, ale wtedy pewne elementy właściwe dla XML bezpowrotnie tracimy.

DataSet, czyli pojemnik po stronie klienckiej w .Net, też w sumie tak działa.

Współczesny programista pracuje głównie z kodem obiektowym (ewentualnie strukturalnym) i z myślą o uwolnieniu go od myślenia w kategoriach relacji powstały rozwiązania do mapowania obiektowo-relacyjnego. Bardzo ciekawe pomysły w tej dziedzinie rozwija ostatnio Microsoft. Linq (Language Integrated Query) to koncepcja pozwalająca zapisać kwerendę w naturalny sposób dla określonego języka .Net. Na razie obsługiwane są C# (3.0) i VB .Net 9.0.

Linq połączy wszystko

Obiekty wchodzą w relacje

Projektant obiektów Dlinq

Linq wymaga wprowadzenia nowych rozszerzeń do języków programowania. Dodany został mechanizm niejawnego typowania, dzięki któremu zmiennej przyznawany jest typ w momencie inicjalizacji. Analogicznie można stworzyć definicję typu, przekazując (np. pośrednio, jako wynik pewnego wyrażenia) zestaw składowych mających się znaleźć w obiekcie. Metody wspomnianych rozszerzeń pozwalają na dodawanie nowych funkcjonalności do istniejących typów niejako "z zewnątrz". W połączeniu z tzw. wyrażeniami lambda (które wyewoluowały z typów anonimowych) można budować drzewa wyrażeń i w ten sposób określać, jakie operacje wykona złożenie pewnych operatorów. Ostatecznie na podstawie takiego drzewa powstaje zestaw danych, a nie kod.

Technologia Linq występuje w trzech postaciach. Pierwsza (Linq) operuje na strukturach typu tablice. Druga (XLinq) pozwala przetwarzać dokumenty XML. Trzecia (DLinq) przeznaczona jest do pracy z bazą danych. W majowej wersji CTP pojawił się czwarty mechanizm (DataSetLinq) pozwalający manipulować zawartością DataSet. Do DLinq (obsługującego bazy danych) dodany został specjalny projektant Visual Studio .Net. Służy on do definiowania struktur, które potem określają, z jakich elementów można budować wyrażenia.

Obsługiwane jest dziedziczenie (tzn. strukturę bazodanową można zmapować w taki sposób, by wskazać, które elementy definiują relację generalizacja-specjalizacja). Można też stosować procedury przechowywane i precyzować sposób aktualizacji tabel.

Wykorzystując mechanizmy Linq, można zbudować wyrażenia wywodzące się z dowolnej struktury, którą da się opisać w postaci kolekcji obiektów. Taką strukturą mogą być relacyjna baza danych, kolekcja, tablica czy dokument XML. Ważne jest to, że można dodawać własne providery obsługujące inne podstawowe pojemniki. Dzięki temu zapytanie może wyglądać następująco:

var q = (

from c in db.Customers

where c.City == "London"

select c)

.Including (c => c.Orders

.Including (o => o.OrderDetails));

Bardzo ciekawym zastosowaniem Linq jest projekt BLINQ, który pozwala automatycznie generować strony ASP .Net na podstawie struktury bazy danych. Gdy użytkownik filtruje czy dynamicznie przełącza się pomiędzy stronami, składane wyrażenia DLinq powodują generowanie odpowiednich zapytań do bazy danych.

ADO .Net Entity Data Model

DLinq jest mechanizmem działającym na dosyć niskim poziomie. Microsoft ma jednak zamiar udostępnić rozwiązanie do modelowania danych na "wyższym" poziomie abstrakcji jako element ADO .Net. Zgodnie z klasycznym podejściem wyróżniane jest kilka warstw modelowania. Model fizyczny określa technikalia związane z przechowywaniem informacji. Model logiczny precyzuje ogólną klasę pojemników danych. Najczęściej używany jest model relacyjny (zwykle podział danych jest dokonywany zgodnie z tzw. 3 postacią normalną) - z tabelami, wierszami, kluczami obcymi, związkami itp. Wyżej znajduje się model koncepcyjny operujący pojęciami specyficznymi dla pewnej domeny wiedzy. Tu właśnie definiowane są struktury ADO .Net EDM (Entity Data Model), które określają obiekty biznesowe.

Microsoft Entity Framework Architecture zakłada, że w modelu pojawiają się dodatkowe komponenty mapujące, pozwalające w naturalny sposób przejść od modelu logicznego aż do warstwy prezentacyjnej. Na samym dole hierarchii znajduje się provider dla danego źródła fizycznego, np. motoru SQL Server. Map Provider to moduł dokonujący transformacji pomiędzy strukturą koncepcyjną a logiczną. Oprócz mapowania można za jego pomocą definiować dokładny przebieg aktualizacji danych, co jest użyteczne, bo zwykle zmiana w encji biznesowej może wpływać na wiele obiektów bazodanowych.

Map Provider obejmuje także usługi związane z metadanymi. Z zapowiedzi wynika, że będą one opisywały związki pomiędzy obiektami oraz wskazywały miejsce zapisu informacji o tych związkach. Usługi te mają się integrować pojęciowo z dziedzinowymi językami programowania DSL (Domain Specific Language), które będą mogły być użyte do modelowania całego rozwiązania. Map Provider ma mieć taki sam model jak normalne providery ADO .Net, ale dodatkowo polecenie może być sformułowane nie tylko jako eSQL (specjalny dialekt EDM), ale też jako drzewo wyrażeń (np. to z Linq).

EFA działa w modelu bezpołączeniowym, podobnie jak DataSet, ale wykorzystuje encje i kolekcje, a nie wiersze i tabele. Microsoft zapowiedział, że wraz z ADO .Net 3.0 (tak ma się nazywać kolejna wersja ADO połączona z EFA) pojawi się także nowy komponent do buforowania kolekcji po stronie klienckiej i synchronizacji ich z pojemnikiem działającym po stronie serwera. Ostateczna wersja EDM to prawdopodobnie .Net 4.0 (wersja 3.0 to wersja WinFX - która ma być dostępna wraz z Windows Vista).

Od WinFS do ADO .Net 3.0

WinFS pokazany na konferencji PDC 2003 miał być nowym, relacyjnym systemem plików separującym pliki od zawartych w nich informacji i pozwalającym na pełnotekstowe wyszukiwanie informacji oraz powiązań między nimi. WinFS miał sprawić, że zniknie pojęcie folderu, a zastąpi je widok z odpowiednio wyfiltrowanymi danymi. Taki na przykład folder "Moje dokumenty" miał być dynamicznym widokiem dokumentów w różnych układach. Z punktu widzenia programisty WinFS miał być obsługiwany jako ciąg obiektów, struktura XML albo źródło danych, do którego można było zadawać zapytania T/SQL jak do bazy danych. Schemat systemu plików miał być dowolnie rozszerzany - programista miał możliwość dodania zupełnie nowego typu "elementu" w systemie plików, określenia jego atrybutów, domyślnych relacji (XML lub klasa .Net).

Oryginalne plany uległy poważnym zmianom. Obecnie strategia Microsoftu zakłada włączanie elementów koncepcji WinFS do ADO.Net EDM. Przykładem są encje i relacje. Natomiast pojemnikiem na dane (relacyjne, hierarchiczne i nieustrukturyzowane) ma być następna wersja Microsoft SQL

Server o kodowej nazwie Katmai. A zatem nie będzie oddzielnego API dla WinFS jako rozszerzenia NTFS. Nie będzie także zapowiadanej wersji beta 2 WinFS.

Dla tych, którzy nie pamiętają: w czasach Beta 1 technologii .Net 1.0 Microsoft prezentował koncepcję ObjectSpaces. To było pierwsze podejście Microsoftu do zagadnienia mapowania obiektowo-relacyjnego. Później ObjectSpaces przemienił się w WinFS, a obecne WinFS zostało wcielone do DLinq i ADO .Net EDM, które są rozwinięciem tej koncepcji.

Microsoft nie oferował dotychc as narzędzia "klasy produkcyjnej" przeznaczonego do mapowania obiektowo-relacyjnego. Jedynym takim mechanizmem był projektant DataSet, pozwalający definiować postać dokumentu z tabelami dostępnego po stronie klienckiej. Za pomocą Visual Studio .Net 2005 można zdefiniować operatory wypełniające DataSet danymi z bazy, a całość zamknąć w jednym obiekcie biznesowym.

Dzięki Linq można uzyskać analogiczną strukturę obiektową dla różnych serwerów baz danych - poza, oczywiście, pewnymi subtelnościami. Czy i jak DLinq będzie w sposób otwarty wspierał bazy inne niż Microsoft SQL Server - tego na razie nie wiadomo. ADO .Net EDM operuje pojęciami wyższego rzędu i w naturalny sposób związek z bazą jest dosyć luźny.

Niby podobne, ale nie do końca

DLinq i ADO .Net EDM mogą się wydawać technologiami częściowo nakładającym się, co jednak nie jest do końca prawdą. Główną zaletą Linq jest ujednolicenie "zapytań o dane". Dzięki rozszerzeniom metod i "drzewom wyrażeń" w C# 3.0 można efektywnie takie wyrażenie przełożyć na różne zapytania do pojemników fizycznie przechowujących dane. Linq posługuje się dość ogólnym pojęciem zbioru, w który łatwo można wpasować różne "byty aplikacyjne". Programista tak samo pracuje z XML, DataSet i bazą danych i może łączyć zapytania do różnych źródeł danych.

ADO .Net EDM operuje na wyższym poziomie abstrakcji niż Linq. W DLinq mamy odwzorowane to co jest w bazie (niemal na zasadzie 1: 1), natomiast definiując encję w EDM samodzielnie określa się, które elementy mają być traktowane jak obiekty. EDM pozwala więc definiować struktury w bardziej elastyczny sposób. W przyszłości pojawi się jeszcze ELinq - rozwiązanie Linq przeznaczone do pracy z encjami EDM (obok istniejącego już Linq dla DataSet). W jednej aplikacji będzie można "mieszać" ELinq, DataSetLinq i DLinq w ramach modułów bezpośrednio odpowiedzialnych za pracę z danymi. Przed architektem będzie więc stało skomplikowane zadanie wybrania właściwych narzędzi.

Inne rozwiązania ORM

Na rynku dostępnych jest bardzo dużo rozwiązań oferujących mapowanie między światem relacyjnym a obiektowym. Umownie można je podzielić na kilka grup. Pierwsza to rozwiązania, które na podstawie pewnych metainformacji generują kod. Używając CodeSmith albo darmowego MyGeneration, można na podstawie schematu bazy danych stworzyć wzorzec Data Access Layer (DAL). Drugi typ rozwiązania to deKlarit - pakiet przeznaczony do pisania aplikacji na podstawie modelu bazy. W tym przypadku programista dostaje wygenerowaną aplikację obejmującą DAL, framework biznesowy i interfejs użytkownika Windows Forms lub ASP .Net. Warto wspomnieć o nHibernate - przeniesionym do .Net ze świata Javy pakiecie Hibernate Core pozwalającym trwale zapisać strukturę obiektową w bazie danych. Z kolei LLBLGEN Pro automatycznie generuje strukturę obiektową na podstawie struktury relacyjnej bazy. Dysponuje przy tym całkiem wygodnym schematem encji, filtrów, a nawet specjalnym trybem, który pozwala na stosowanie bufora typu lazy read (encja jest wczytywana dopiero wtedy gdy wykonane zostanie odwołanie do niej). Tego typu rozwiązania zwykle są nastawione na dużą automatyzację, np. aby szybko utworzyć obiekty dla kilku tysięcy tabel. Zarówno DLinq, jak i EDM są raczej rozwiązaniami do pracy interaktywnej, dla projektanta.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200