Entity Framework dostarcza trzy różne podejścia do odwzorowywania encji modelu domeny na relacyjne obiekty bazy danych:

- database-first: zaczynamy od utworzenia bazy danych, a EF automatycznie generuje klasy modelu na podstawie struktury bazy danych

- model-first: zaczynamy od utworzenia klas modelu w dedykowanym designerze i mapujemy je na istniejącą bazę danych lub EF generuje bazę na podstawie stworzonego modelu

- code-first: zaczynamy od utworzenia klas modelu wprost w kodzie i mapujemy na obiekty bazy danych.

W dalszej części zamierzam skupić się na tym ostatnim podejściu. Według mojego może odrobinę subiektywnego odczucia jest to jedyny wartościowy sposób użycia EF. Kontrowersyjne? Otóż nie do końca. Patrząc przez pryzmat programisty używającego przez kilka lat NHibernate (ostrzegałem, że może nie być obiektywnie) takie podejście wydaje się być zupełnie naturalne.

Rozpoczynam od utworzenia obiektów modelu domeny – obiektów POCO rzecz jasna – nie myśląc na tym etapie o projektowaniu relacji bazy danych (Domain Driven Development). W następnej kolejności tworzę odpowiednią strukturę bazy danych i mapuję na nią klasy modelu. Entity Framework potrafi sam wygenerować strukturę bazy danych na podstawie klas modelu stosując analogiczne nazewnictwo do nazw klas i ich właściwości. Wygodne rozwiązanie, jednak życie pokazuje, że mało praktyczne szczególnie w dużych projektach. Każdy z nas ma jakieś przyzwyczajenia co do nazewnictwa obiektów w bazie danych – ja również i one się nie pokrywają z konwencjami nazewniczymi dostarczanymi przez EF. Przyzwyczajenia owszem można zmienić, co jednak gdy korporacja posiada ścisłe reguły co do nazywania obiektów w bazie danych? Głową muru się nie przebije, stąd potrzeba elastycznego mechanizmu konfiguracji mapowania. Na początku się obawiałem na jak wiele pozwoli nam tutaj Microsoft. Niepotrzebnie, bo za pomocą fluent API można naprawdę dużo. Nie jest to co prawda tak dużo jak oferuje NHibernate, ale nie powinno to wpłynąć na wygodę używania Entity Framework Code-First.

Korzystając z podejścia code-first mamy trzy sposoby na mapowanie obiektowo-relacyjne. Po pierwsze, wspomniane już, automatyczne generowanie struktury bazy danych; po drugie mapowanie przy pomocy atrybutów z przestrzeni nazw System.Data.Annotations; i po trzecie preferowane przeze mnie ze względu na swoje możliwości – fluent API.

Nie uważam, aby mapowanie przy pomocy atrybutów było złym rozwiązaniem, po prostu fluent API wydaje mi się lepsze. Dzięki temu mogę odseparować model od bazy danych i stworzyć go bardziej „czystym”. Pod tym względem zdecydowanie jestem purystą.

Przeanalizujmy sposób użycia fluent API na podstawie projektu prostej aplikacji konsolowej stworzonej w Visual Studio, którą można pobrać stąd. Trywialny model domeny (mocno anemiczny) posiada jedynie cztery klasy. Nie w tym rzecz jednak. Różne relacje między tymi klasami obrazują to co najważniejsze w kontekście konfiguracji mappingu. Projekt pokazuje jak zmapować relacje między obiektami typu: many-to-one (Uzytkownik->Rola), one-to-many (Uzytkownik->Komputer) czy many-to-many (Rola->Uprawnienie).

Przejdźmy do tworzenia wspomnianego modelu domeny, dodając do projektu cztery następujące klasy:

public class Komputer

{

public long? Id { get; set; }

public string Nazwa { get; set; }

public string AdresIP { get; set; }

}

public class Uprawnienie

{

public long? Id { get; set; }

public string Nazwa { get; set; }

public IList<Rola> Role { get; set; }

}

public class Rola

{

public long? Id { get; set; }

public string Nazwa { get; set; }

public IList<Uprawnienie> Uprawnienia { get; set; }

}

public class Uzytkownik

{

public long? Id { get; set; }

public string Login { get; set; }

public bool CzyAktywny { get; set; }

public Rola Rola { get; set; }

public IList<Komputer> Komputery { get; set; }

}

Kolejnym krokiem jest wygenerowanie stosownej struktury tabel w bazie danych zgodnie z przyjętą przez siebie/organizację konwencją. Pomijam opis tego procesu, bo może być wykonany na wiele sposobów. Począwszy od „ręcznego” utworzenia tabel, aż po skorzystanie z własnych dedykowanych do tego narzędzi. Niejednokrotnie jest tak, że otrzymujemy już gotową strukturę bazy danych od programisty baz danych. W załączonym projekcie znajduje się skrypt SQL tworzący wymaganą strukturę bazy danych (dla MS SQL Server).

Mamy model domeny w postaci klas, mamy strukturę bazy danych – czas przejść do mapowania. Zanim jednak to zrobimy, dodajmy jeszcze connection string do naszej bazy danych do pliku konfiguracyjnego aplikacji app.config:

<connectionStrings>

<clear/>

<addname=„ConnStr„

connectionString=„Data Source=(local);Initial Catalog=EF_CODE_FIRST_SAMPLE_DB;Integrated Security=SSPI;„

providerName=„System.Data.SqlClient„ />

</connectionStrings>

Kluczowym elementem aplikacji z wykorzystaniem Entity Framework code-first jest klasa DbContext z przestrzeni nazw System.Data.Entity. Pełni ona rolę wzorca Repository, a także jednocześnie Unit Of Work. To dzięki tej klasie możemy wykonywać na encjach modelu wszelkie operacie CRUD w ramach transakcji. Oznacza to, że naszym kolejnym krokiem jest utworzenie właśnie klasy dziedziczącej po DbContext. Zróbmy to:

public class ModelContext : DbContext

{

public ModelContext() : base() { }

public ModelContext(string stringNameOrConnectionString) : base(stringNameOrConnectionString) { }

}

Użyłem tu przeciążenia konstruktora, które pozwoli nam podać nazwę connection stringa z pliku konfiguracyjnego lub wprost podać connection string do bazy danych.

Kolejna bardzo istotna klasa, funkcjonująca nierozerwalnie z DbContext, to DbSet<>. Reprezentuje kolekcję encji danego typu w ramach kontekstu jaki definiuje nam klasa DbContext. Dodajmy zatem stosowne kolekcje encji do klasy ModelContext:

public DbSet<Rola> Role { get; set; }

public DbSet<Uzytkownik> Uzytkownicy { get; set; }

W tym momencie możemy przejść już do samego mapowania z użyciem fluent API. W związku z tym w klasie ModelContext musimy przesłonić metodę OnModelCreating:

protected override void OnModelCreating(DbModelBuilder modelBuilder)

{

base.OnModelCreating(modelBuilder);

}

To jest właśnie to miejsce w którym definiujemy konfigurację mappingu. Możemy to zrobić wprost w tej metodzie lub lepszym pomysłem będzie wydzielenie mappingu poszczególnych encji do dedykowanych klas. Sprawdza się to szczególnie w większych projektach. W tym celu należy utworzyć klasę dziedziczącą po EntityTypeConfiguration<> dla każdej encji:

public class KomputerMapping : EntityTypeConfiguration<Komputer>

{

public KomputerMapping()

: base()

{

this.HasKey(e => e.Id).Property(e => e.Id).HasColumnName(„ID_KOMPUTERA”);

this.Property(e => e.Nazwa).HasColumnName(„NAZWA”);

this.Property(e => e.AdresIP).HasColumnName(„ADRES_IP”);

this.ToTable(„KOMPUTERY”);

}

}

public class UprawnienieMapping : EntityTypeConfiguration<Uprawnienie>

{

public UprawnienieMapping()

: base()

{

this.HasKey(e => e.Id).Property(e => e.Id).HasColumnName(„ID_UPRAWNIENIA”);

this.Property(e => e.Nazwa).HasColumnName(„NAZWA”);

this.ToTable(„UPRAWNIENIA”);

}

}

public class RolaMapping : EntityTypeConfiguration<Rola>

{

public RolaMapping()

: base()

{

this.HasKey(e => e.Id).Property(e => e.Id).HasColumnName(„ID_ROLI”);

this.Property(e => e.Nazwa).HasColumnName(„NAZWA”);

this.HasMany<Uprawnienie>(u => u.Uprawnienia).WithMany(u => u.Role).Map(

m => m.ToTable(„UPRAWNIENIA_DLA_ROLI”)

.MapLeftKey(„ID_ROLI”)

.MapRightKey(„ID_UPRAWNIENIA”)

);

this.ToTable(„ROLE”);

}

}

public class UzytkownikMapping : EntityTypeConfiguration<Uzytkownik>

{

public UzytkownikMapping()

: base()

{

this.HasKey(e => e.Id).Property(e => e.Id).HasColumnName(„ID_UZYTKOWNIKA”);

this.Property(e => e.Login).HasColumnName(„LOGIN”);

this.Property(e => e.CzyAktywny).HasColumnName(„CZY_AKTYWNY”);

this.HasRequired(e => e.Rola).WithMany().Map(p=>p.MapKey(„ID_ROLI”));

this.HasMany(e => e.Komputery).WithOptional().Map(p => p.MapKey(„ID_UZYTKOWNIKA”)).WillCascadeOnDelete();

this.ToTable(„UZYTKOWNICY”);

}

}

To jest kompletny mapping dla naszego modelu domeny. Przyjrzyjmy się kluczowym elementom. Wywołanie HasKey() wskazuje które property jest primary key w naszej encji, natomiast Property() umożliwia zmapowanie konkretnej właściwości na konkretną kolumnę w tabeli bazy danych. Użyłem wywołania HasColumnName(), aby wskazać inną nazwę kolumny w tabeli – nieodpowiadającą konwencji nazewniczej EF. To wszystko okraszone jest wywołaniem ToTable(), gdzie wskazujemy nazwę tabeli odpowiadającą encji. Mapowanie klucza głównego i właściwości typów prostych wygląda na niezbyt skomplikowane. Czas przejść do mapowania relacji między obiektami.

Na pierwszy ogień many-to-one czyli zwykła referencja do innego typu encji z naszego modelu. Dobrym przykładem jest powiązanie użytkownika z rolą. Klasa Uzytkownik posiada referencję do klasy Rola, przy czym jest to referencja wymagana. Mapujemy to za pomocą wywołania HasRequired() wskazując nazwę właściwości przechowującej referencję do klasy Rola. W związku z tym, że także w tym wypadku konwencja nazewnicza klucza obcego w tabeli nie odpowiada tej z EF należy wskazać nazwę. Robimy to przy pomocy wywołania MapKey() podając nazwę klucza obcego w tabeli. Kompletny przykład mapowania takiej relacji wygląda następująco:

this.HasRequired(e => e.Rola).WithMany().Map(p=>p.MapKey(„ID_ROLI”));

W sytuacji kiedy property przechowujące referencję nie jest wymagane, to zamiast HasRequired() użyjemy HasOptional().

Innym typem relacji jest kolekcja czyli one-to-many. Przeanalizujmy to na przykładzie kolekcji elementów Komputer w klasie Uzytkownik. Do zmapowania listy używamy wywołania HasMany() podając jako parametr property – za pomocą wyrażenia lambda oczywiście – które wskazuje naszą kolekcję. W związku z tym, iż ta właściwość nie jest wymagana używamy WithOptional(). Jak się wszyscy domyślają w przeciwnym wypadku użylibyśmy WithRequired(). Wywołanie Map() z MapKey() wygląda już znajomo i używamy go by wskazać klucz obcy w tabeli zawierającej rekordy będące elementami listy. Dodatkowo na końcu znajduje się wywołanie metody WillCascadeOnDelete(). Cóż to takiego? Nic innego jak wskazanie czy podczas usunięcia elementu nadrzędnego ma być wywołane kaskadowe usunięcie elementów podrzędnych, czyli tych w naszej kolekcji. Cały przykład wygląda następująco:

this.HasMany(e => e.Komputery).WithOptional().Map(p => p.MapKey(„ID_UZYTKOWNIKA”)).WillCascadeOnDelete();

Na koniec najbardziej skomplikowana relacja czyli many-to-many. Przykładem takiego powiązania jest wzajemna relacja między obiektami Rola i Uprawnienie. Rola posiada kolekcję elementów Uprawnienie i vice versa, tj. Uprawnienie posiada kolekcję elementów Rola. Aby zmapować takie powiązanie na postać relacyjną potrzebujemy dodatkowej tabeli. Ta tabela przechowuje pary identyfikatorów roli i uprawnienia. Dobrze, aby kluczem głównym takiej tabeli była owa para identyfikatorów. Mapowania wykonujemy z jednej ze stron np. z encji Rola. Spójrzmy na przykład:

this.HasMany<Uprawnienie>(u => u.Uprawnienia).WithMany(u => u.Role).Map(

m => m.ToTable(„UPRAWNIENIA_DLA_ROLI”)

.MapLeftKey(„ID_ROLI”)

.MapRightKey(„ID_UPRAWNIENIA”)

);

Wywołujemy generyczną wersję metody HasMany, podając jako parametr generyczny typ elementu kolekcji, a jako parametr wywołania właściwość klasy przechowującą kolekcję tych elementów. Następnie w wywołaniu WithMany podajemy wskazanie w drugą stronę tj. w tym przypadku na kolekcję elementów Rola. Ostatni element mapowania relacji wiele do wielu i najważniejszy to wskazanie wspomnianej tabeli powiązania w Map(). Nazwę tabeli podajemy w wywołaniu ToTable i wskazujemy nazwy kolumn kluczy obcych do obu typów encji/tabel. Należy dodać, że left key to klucz obcy wskazujący na typ którego mapping opisujemy, a right key to klucz obcy wskazujący na typ elementów kolekcji.

Tak by wyglądał przyznaje, że dość pobieżny opis mapowania encji w moim prostym projekcie. Uważam, że fluent API jest na tyle intuicyjne i samo-opisujące iż czysty kod wielu z Was najlepiej pomoże uchwycić to wszystko.

Ostatnim krokiem jest wskazanie, które z klas „konfiguracyjnych” definiują mapping których encji. To bardzo proste – w metodzie OnModelCreating dodajemy:

modelBuilder.Configurations.Add(newRolaMapping());

modelBuilder.Configurations.Add(newUzytkownikMapping());

modelBuilder.Configurations.Add(newKomputerMapping());

modelBuilder.Configurations.Add(newUprawnienieMapping());

Zachęcam jeszcze do przeanalizowania kompletnego projektu zamieszczonego tutaj.

Na koniec nie mógłbym nie podkreślić tego, iż trzymam kciuki za dalszy rozwój Entity Framework właśnie w tym kierunku – jedynym słusznym kierunku.

Aby jednak móc skorzystać z tego cudu jakim jest persistence ignorant w EF, w Visual Studio należy doinstalować odpowiedni generator. Ta operacja w Visual Studio 2010 jest dziecinnie prosta, gdyż wystarczy po utworzeniu modelu EF z menu kontekstowego designera encji wybrać „Add Code Generation Item…” -> Online Templates -> Templates -> Database -> „ADO.NET C# POCO Entity Generator”. Po zainstalowaniu dodatku zobaczymy w naszym solution pliki szablonów *.tt oraz związany z nimi custom tool TextTemplatingFileGenerator.

Dzięki szablonom i generatorowi możemy się cieszyć encjami POCO w EF. Obiekty encji teraz to czyste obiekty, które nie dziedziczą już ze specyficznej klasy bazowej jak to w „starym” EF było. Dodać należy jeszcze tylko tyle, że działa tu lazy loading oraz change tracking.

Jest dobrze, ale czy nie może być lepiej? Zawsze może! W związku z tym zawsze można wprowadzić modyfikacje do szablonów generatora, aby przystosować generowany kod jeszcze bardziej do własnych potrzeb. Zachęcam do zapoznania się z POCO Entity Generator dla Entity Framework. Hmm … może to właśnie EF kiedyś zastąpi NH w moich projektach (?).

• obiekty domeny nie są POCO
• O/R mapper nie jest „Persistence Ignorance”

Obie te dwie cechy mają ze sobą wiele wspólnego. Przede wszystkim mój kod z użyciem EF posiada zbyt wiele zależności do konkretnych technologii łamiąc zasady architektury aplikacji biznesowych jak i wielu wzorców projektowych. Oczywistym mogło by się wydawać to, iż O/R Mapper nie powinien wymagać dziedziczenia encji po własnych klasach. Tak samo oczywiste jest to, że domena aplikacji nie powinna mieć świadomości o mechanizmie zapisu/pobierania danych. A jednak! Bez sarkazmu i zupełnie szczerze mówiąc, nie rozumiem tak wielkiej ignorancji twórców EF. Przyglądam się i nadal kibicuję EF mając nadzieję, że kolejne wersje przyniosą znaczące zmiany w tych dwóch kwestiach. Tymczasem zostaję przy sprawdzonym NHibernate.

Niespełniona reguła walidacyjna na wskazanym property obiektu powoduje wyświetlenie ikony przy odpowiedniej kontrolce. Szczegóły niespełnionych reguł są wyświetlane w tooltipie. Wiemy zatem co chcemy uzyskać, teraz pytanie jak?

Zacznę może od samego obiektu który podlega walidacji. W aplikacjach biznesowych jest to z reguły jakiś DataTransferObject. Kontrolka ErrorProvider potrzebuje, aby dostarczyć do niej informacji o niespełnionych regułach walidacyjnych. Ta informacja to zwykły string czyli komunikat który ma się wyświetlić użytkownikowi. Odpowiedzialny za to jest interfejs IDataErrorInfo.

Interfejs jest dość prosty bo posiada tylko dwie właściwości:

• string Error { get; }
• string Item[string columnName] { get; }

Jak się okazuje dalej implementacja tego interfejsu w naszej klasie DataTransferObject również nie jest trudna. Zakładam, że nasz DataTransferObject posiada już sam mechanizm walidowania np. wykorzystujący całkiem poręczny Application Validation Block pochodzący z Enterprise Library. Nie pozostaje teraz nic innego jak zaimplementować IDataErrorInfo w naszej klasie DataTransferObject.

Właściwość Error zwraca nam listę komunikatów o niespełnionych regułach na wskazanym obiekcie. Indekser zwraca nam natomiast listę komunikatów niespełnionych reguł dla wskazanej właściwości obiektu. Parametr columnName określa nazwę właściwości obiektu.

Przedstawiona klasa nie posiada pełnej implementacji, a jedynie te elementy które są istotne w omawianym kontekście. Oczywiste jest, że klasa musi mieć w tym wypadku kolekcję niespełnionych reguł walidacyjnych, która jest odpowiednio uzupełniana podczas wywołania walidacji. Na tej kolekcji zresztą bazują zaimplementowane właściwości z interfejsu IDataErrorInfo. W ten sposób chciałem pokazać, iż sam mechanizm walidacji jest zupełnie niezależny od implementacji IDataErrorInfo i po wprowadzeniu kilku własnych interfejsów może być łatwo wymieniany na inny.

Teraz możemy zająć się już interfejsem użytkownika. Pierwsze co należy zrobić to położyć na widoku kontrolkę ErrorProvider, np. przeciągając z toolboxa. Kolejnym krokiem jest zbindowanie naszego obiektu (dziedziczącego z DataTransferObject) z kontrolkami i przypisanie tego obiektu jako źródła danych do właściwości DataSource kontrolki ErrorProvider. Jeśli dodajemy kontrolkę ErrorProvider nie poprzez designera warto pamiętać o ustawieniu właściwości ContainerControl na odpowiednią formę/kontrolkę.

Sama kontrolka ErrorProvider posiada jeszcze kilka ciekawych właściwości jak: BlinkRate (częstotliwość pulsowania), BlinkStyle (kiedy ma pulsować ikonka) oraz Icon.

Powodzenia w implementacji wizualizacji wyników walidacji we własnej aplikacji w ten jakże prosty sposób.

Kod źródłowy do wglądu zamieszczam tutaj. Tak na marginesie cały pomysł jak i jego implementacja powstała podczas jednego z programów rozrywkowych z tępym żartem granego w pewnej stacji na trzy litery w poniedziałkowe wieczory. A więc jak sądzę wszystko to trwało nie więcej jak 60 minut (z reklamami) – tłumaczę się na zaś jakby jednak coś nie działało;).

• interfejs modelu (BeezDev.SpringWCFApplication.Model.Interface)
• implementacja modelu (BeezDev.SpringWCFApplication.Model)
• konsolowa aplikacja hostująca serwisy aka server (BeezDev.SpringWCFApplication.Server)
• okienkowa aplikacja klient (BeezDev.SpringWCFApplication.Client)

Aplikacja posiada jeden serwis HelloService z jedną metodą SayHello przyjmującą jako parametr jeden obiekt DTO i zwracającą inny typ obiektu DTO. Jakże wyszukana logika mówi: „podaj mi swój login, a zostaniesz przywitany”. Aplikacja serwera posiada referencję do interfejsu modelu jak i jego implementacji, natomiast już klient posiada tylko referencję do interfejsu modelu.
Przyjrzyjmy się najpierw konfiguracji serwera. Nie będę oczywiście omawiał całości konfiguracji Spring.NET, a jedynie te elementy które są istotne w kontekście WCF. Pierwsza sprawa to definicja serwisu w kontenerze IoC Springa.
Generalnie przy migracji z .NET Remoting ona istnieje. Jedyna zmiana, której ewentualnie musimy dokonać, to oznaczyć serwis aby nie był uruchamiany jako singleton (singleton=”false”). Jak podaje dokumentacja Spring.NET ten typ aktywacji obiektu nie współpracuje poprawnie z technologią WCF. Przyjmijmy to jako pewnik i na tym etapie nie wnikajmy w szczegóły.
Cała moc Springa drzemie w eksporterach serwisów, a więc należy zdefiniować odpowiedni dla WCF:

Nie ma tu nic nowego, poza szczególnym typem eksportera serwisu Spring.ServiceModel.ServiceExporter.
Od serwera wymaga się hostowania naszego serwisu i do tego służy klasa ServiceHost. To kolejna zmiana w kodzie jaką musimy wykonać w stosunku do .NET Remoting. Zakładając, że aplikacja hostująca nie jest częścią modelu aplikacji, a więc ta zmiana się nie liczy;).
Teraz klient czyli to najciekawsze z punktu widzenia WCF. Zmiany w kodzie? Nie! Żadnych zmian! Aplikacja działa tak samo, tj. pobiera instancję serwisu z kontenera IoC Spring-a i wywołuje jego metody. Zatem wszystkie zmiany ograniczą się do pliku konfiguracyjnego.
Definiujemy ChannelFactory dla naszego serwisu:

Jako parametr generyczny podajemy typ naszego serwisu i kolejna rzecz wymagająca wyjaśnienia to argument konstruktora. Tutaj przekazujemy nazwę endpointa-a z konfiguracji WCF-a. O tym jeszcze wspomnę później.

Następnie definicja naszego serwisu:

Jako klasę fabrykującą wskazujemy obiekt zdefiniowany wcześniej, a metoda fabrykująca to oczywiście CreateChannel.
To wszystko! No prawie wszystko;). Pozostaje kwestia konfiguracji samego WCF, która jest niejako poza tematem tego artykułu. Wspomnę tylko, że konfiguracji dokonujemy w tradycyjny sposób, tj. w sekcji system.serviceModel pliku app.config. W przykładzie użyłem hostowania serwisów po protokole TCP z binarną serializacją. Po szczegóły związane z cała magią konfiguracji WCF-a tzw. ABC odsyłam do dokumentacji.

Pełne solution tutaj. Miłej zabawy!

Co tu widać? Dziedziczymy po wspomnianej klasie i uzupełniamy właściwość ConfigLocations wskazując nasz plik konfiguracyjny. W tym wypadku jest to tylko część konfiguracji dotycząca samych serwisów. Dzięki temu Spring.NET korzystając z konfiguracji zapisanej w Services.xml wstrzyknie nam instancję klasy AbonenciService odpowiednio ją inicjując.
Tak wygląda plik Services.xml:

Widzimy, że do serwisu dodatkowo została wstrzyknięta instancja klasy AbonentDAO.

W zdecydowanej większości systemów biznesowych dane są zapisywane w jakimś repozytorium, którym najczęściej jest baza danych. Istotną kwestią jest to, że takie dane dodane czy zmodyfikowane podczas testu nie powinny mieć wpływu na całość systemu. Oznacza to tyle, że test powinien się wykonywać w transakcji i wszelkie modyfikacje danych nie powinny być widoczne poza tą transakcją. Takie właśnie zachowanie daje nam Spring.NET, tj. w ramach testu tworzy transakcję, a następnie ją wycofuje. Odpowiedzialna za to jest jedna z klas bazowych AbstractTransactionalDbProviderSpringContextTests. Klasa ta bazuje na IPlatformTransactionManager, który jest dostarczony w ramach konfiguracji aplikacji. W pewnych przypadkach takie domyślne zachowanie nie jest wskazane, dlatego też mamy możliwość dziedziczenia po tej klasie i wprowadzenia własnych modyfikacji. Może nas np. w szczególnych przypadkach interesować zatwierdzenie transakcji zamiast domyślnego jej wycofania. Można to osiągnąć poprzez wywołanie metody SetComplete(). Podobnie możemy chcieć wycofać transakcję przed zakończeniem testu – wywołując EndTransaction();

Spring.NET dostarcza nam prosty, ale jakże pomocny mechanizm wsparcia dla testów jednostkowych NUnit. Pozwala nam to zaoszczędzić wiele cennego czasu przy budowaniu testów naszej aplikacji.

W świecie .NET mamy do dyspozycji kilka różnych technologii pozwalających budować i publikować nam serwisy jak: .NET Remoting, WebServices, Enterprise Services czy wreszcie WCF.

Na etapie projektu aplikacji często nie wiemy lub nie chcemy się zajmować takimi konkretami jak technologia, której użyjemy do budowy naszych serwisów. Na tym etapie podchodzimy do serwisów w sposób bardziej abstrakcyjny. Jednak przychodzi moment, gdy musimy się zdecydować na któreś z rozwiązań. Załóżmy, że w pierwszej kolejności wybieramy .NET Remoting, ale po dłuższym zastanowieniu stwierdzamy jednak, że nasze serwisy będą wystawione na świat w postaci WebService i hostowane na serwerze IIS. Taka zmiana wymagać będzie od nas pewnego nakładu pracy i często wprowadza lekkie zamieszanie. A co gdyby tylko na poziomie konfiguracji określać jaką technologią nasze serwisy mają być hostowane? Brzmi świetnie!!!
Tu z pomocą przychodzi Spring.NET, a właściwie cały mechanizm eksporterów serwisów w Spring.NET.
Spring.NET wprowadza kolejną warstwę abstrakcji – eksportera serwisu. Obsługuje wszystkie wymienione wcześniej technologie eksportowania serwisów. Cała konfiguracja, która pozwoli nam wyeksportować serwis jest zupełnie banalna.

Zacznijmy od zdefiniowania dosłownie interfejsu naszego serwisu IAbonenciService.

Mamy bardzo prosty interfejs serwisu tylko z jedną metodą, teraz czas na jego implementację.

Przedstawiłem prostą implementację serwisu, odwołująca się do obiektu DAO jak i obiektu konwertera. Oczywiście instancje obu tych obiektów możemy sobie wstrzyknąć poprzez kontener IoC Springa.

Dodać należy, że dobrym rozwiązaniem będzie umieszczenie interfejsu serwisu w osobnym assembly, np. BeezDev.ExampleSpringApp.Model.Interface, a implementacji w osobnym, np. BeezDev.ExampleSpringApp.Model. Dzięki temu aplikacja klienta będzie posiadała jawną referencję tylko do assembly z interfejsem, a nie implementacją serwisu.

Spróbujmy opublikować nasz serwis poprzez .NET Remoting. Nie będę opisywał szczegółów samej technologii .NET Remoting, bo moim celem jest pokazanie jedynie integracji Spring.NET z .NET Remoting. W sprawie konfiguracji kanałów, portów, aktywacji obiektów (SAO, SAO Singleton, CAO) odsyłam do dokumentacji.

Na pierwszy ogień konfiguracja po stronie serwera. Załóżmy, że nasz serwis hostujemy w zwykłej aplikacji .NET uruchamianej w postaci usługi Windows. Konfiguracja Spring.NET wyglądać będzie następująco:

Co widzimy? Na początek wspomniany wcześniej obiekt typu DAO, dalej definicja serwisu i wstrzyknięcie instancji obiektu DAO. Najciekawsze na koniec – eksport serwisu poprzez .NET Remoting jako SAO Singleton. Właściwość TargetName wskazuje na definicję serwisu, a ServiceName określa nazwę pod jaką będzie widoczny nasz serwis.

To prawie wszystko! Prawie bo reszta to już tylko konfiguracja .NET Remoting, tj.

Po stronie aplikacji klienta konfiguracja jest równie prosta:

Pobranie naszego serwisu po url-u, gdzie protokół (tcp) i port (8008) zdefiniowaliśmy w konfiguracji Remotingu po stronie serwera oczywiście. Nazwa serwisu w url to ta którą podaliśmy w ServiceName.

Konfiguracja .NET Remoting po stronie klienta:

Oto cała konfiguracja, teraz możemy pobrać po stronie klienta instancję serwisu, przy założeniu że aplikacja serwera hostująca nasz serwis jest uruchomiona.

To wszystko i działa! Jeśli zdecydujemy opublikować nasz serwis za pomocą innej technologii praktycznie wszystkie zmiany jakich musimy dokonać ograniczą się do zmian exportera w plikach konfiguracyjnych. Po szczegóły związane z serwisami w Spring.NET odsyłam tradycyjnie do dokumentacji projektu.

To co powinno nas na początku zainteresować to interfejs IPlatformTransactionManager, który wygląda tak:

Spring.Net dostarcza kilka różnych implementacji tego interfejsu, tj.:

• AdoPlatformTransactionManager – obsługa lokalnych transakcji ADO.NET
• ServiceDomainPlatformTransactionManager – obsługa transakcji rozproszonych bazujących na menadżerze Enterprise Services
• TxScopePlatformTransactionManager – obsługa transakcji lokalnych i zdalnych bazująca na System.Transactions
• HibernatePlatformTransactionManager – obsługa transakcji lokalnych dla NHibernate i ADO.NET

Jak widać metoda GetTransaction zwraca odpowiedni obiekt implementujący interfejs ITransactionStatus w zależności od przekazanych parametrów (ITransactionDefinition). Dzięki temu obiekt ITransactionStatus może reprezentować nową lub już istniejącą transakcję.

Co zatem określa obiekt ITransactionDefinition? Przyjrzyjmy się temu bliżej. Oto co definiuje:

• Isolation – poziom izolacji transakcji
• Propagation – pozwala określić czy ma zostać utworzona nowa transakcja czy kod ma być wykonany w istniejącej transakcji
• Timeout – czas działania transakcji po jakim zostanie zgłoszony błąd przekroczenia czasu oczekiwania
• Read-only – ważna właściwość określająca, że dane w transakcji nie będą modyfikowane. Ma to szczególne znaczenie w przypadku NHibernate, bo podnosi wydajność takiej transakcji.

ITransactionStatus zwracany z metody GetTransaction określa status transakcji i niejako jej kontekst wykonania. Zauważmy, że parametr tego typu przyjmują metody Commit i Rollback interfejsu IPlatformTransactionManager.

Najprostszym sposobem powołania do życia menadżera transakcji jest zlecenie tego kontenerowi IoC. W wypadku prostego menadżera dla lokalnych transakcji ADO.NET plik konfiguracyjny wygląda tak:

Jedyne co wymaga wyjaśnienia to DbProvider, ale jego już używaliśmy niejednokrotnie. Menadżerowi transakcji wystarczy przekazać referencję do odpowiedniego DbProvider, który jak widać na przykładzie jest zdefiniowany wyżej.

W wypadku menadżera transakcji bazującego na System.Transactions plik konfiguracyjny wyglądałby dużo prościej:

Tu już nie przekazujemy DbProvidera, ponieważ mechanizm typu System.Transactions to rozproszony system zarządzania transakcjami.

Jeszcze inaczej się przedstawia konfiguracja menadżera transakcji dla NHibernate:

Podobnie jak w wypadku tego pierwszego przekazujemy DbProvidera, ale jeszcze dodatkowo musimy wskazać na odpowiedni SessionFactory. SessionFactory definiowaliśmy w części poświęconej dostępowi do danych poprzez NHibernate, więc nie będę tego ponownie przedstawiał.

Zarządzanie transakcjami w Spring.Net jest możliwe na dwa sposoby: deklaratywnie i imperatywnie. Jak podaje dokumentacja większość użytkowników wybiera sposób deklaratywny. Hmm … ja też! Podstawowy powód mojego wyboru jest taki, iż ta metoda wymaga naprawdę niewiele wysiłku, a także i może przede wszystkim, nie „wplątuje” się w kod logiki biznesowej aplikacji.
Dodatkowe cechy deklaratywnej obsługi transakcji w Spring.NET to możliwość definiowania własnych reguł wycofywania transakcji, czy możliwość kontrolowania procesu działania transakcji, tj. np. wykonania dodatkowego kodu podczas rollback. Możliwe jest to dzięki temu, iż deklaratywna obsługa transakcji opiera się na AOP.

W typowych przypadkach transakcje powinniśmy stosować na poziomie komponentów biznesowych czy serwisów pełniących rolę fasad. Nie stosujemy transakcji na niższym poziomie abstrakcji, tj, bezpośrednio w obiektach dostępu do danych. Przedstawię prosty przykład serwisu:

Jak widać jedyne co musimy zrobić to opatrzyć metodę serwisu atrybutem [Transaction()]. Tutaj został użyty najprostszy przypadek, ale można również na tym poziomie określić dodatkowe cechy transakcji jak: poziom izolacji, to czy transakcja ma być read-only, itp.

Przyjrzyjmy się teraz przykładowi kodu z poprzedniej części serii poszerzonemu o definicję naszego serwisu:

To jest kompletny w pełni działający przykład na którym można dostrzec: obiekt dostępu do danych, serwis, provider bazy danych, NHibernate-owe SessionFactory oraz to co nas interesuje najbardziej czyli menadżer transakcji dla NHibernate. Wyjaśnienia wymaga jeszcze wpis <tx:attribute-driven/>, który jest niezbędny dla deklaratywnego mechanizmu zarządzania transakcjami. Tutaj został zdefiniowany z domyślnymi parametrami, tj. wskazuje na menadżera transakcji o domyślnej nazwie „transactionManager”. Jeżeli ta nazwa byłaby inna wtedy musielibyśmy to określić tak:

Inna metoda obsługi transakcji w Spring.NET to metoda imperatywna, czyli programowa. To ta mniej preferowana przeze mnie. Do zarządzania transakcjami w ten sposób możemy skorzystać z jednego z dwóch rozwiązań:

• TransactionTemplate
• IPlatformTransactionManager

Pierwsza metoda polega na stosowaniu anonimowych delegatów. Prawda, że ten kod nie wygląda przyjemnie?

Drugie podejście to użycie klasy implementującej IPlatformTransactionManager. Interfejs IPlatformTransactionManager już znamy. Spójrzmy na samo opisujący się przykład, gdzie transactionManager implementuje wspomniany interfejs:

Wygląda prosto i tak też jest w rzeczywistości. Pobieramy instancję ItransactionStatus, a następnie wykonujemy commit na sukces lub rollback w wypadku niepowodzenia przekazując ją jako parametr.

Spring.NET daje nam świetny mechanizm zarządzania transakcjami i zwalania nas od implementowania własnych rozwiązań pozwalając skupić się na właściwym biznesie aplikacji.
Dokumentacja Spring.Net omawia jeszcze szczegółowo wiele aspektów zarządzania transakcjami. Zainteresowanych samym działaniem mechanizmu od kuchni oraz tym jaką rolę w tym wszystkim odgrywa AOP odsyłam do dokumentacji.
W kolejnej części omówię stosowanie serwisów w aplikacjach rozproszonych Spring.NET.

Oto co przemawia za tym rozwiązaniem:

1) Luźnie powiązania.

Podstawową zaletą takiego rozwiązania jest wprowadzenie kolejnego luźniejszego powiązania pomiędzy warstwą logiki biznesowej, a prezentacji. Ma to szczególne znaczenie, kiedy nagle okaże się, iż trzeba dokonać pewnych zmian w warstwie prezentacji. W ten sposób często unikamy modyfikacji w warstwie logiki biznesowej, co wydaje się być dobre.

Przeciwnicy powiedzą: W większości typowych przypadków i tak dokonanie zmian w warstwie logiki biznesowej będzie niezbędne.

2) Różne wymagania.

Encja reprezentująca jakiś fragment naszego biznesu z jednej strony musi komunikować się z klientem (warstwa prezentacji), a z drugiej z repozytorium w którym jest przechowywana (warstwa dostępu do danych). Oba te wymagania nakładają na encje pewne zadania. Patrząc od strony warstwy dostępu do danych to powinno być możliwe wykonanie operacji CRUD na encji. Czy to poprzez procedury składowane, czy mechanizm O/R Mapping-u. Z drugiej strony encja powinna współpracować z warstwą prezentacji, tj. bindować się z kontrolkami, obsługiwać mechanizmy powiadamiania o niespełnionych regułach walidacyjnych itp. To znowu nakłada na każdą encje zupełnie inne zadania. Stąd warto rozdzielić te dwa jakże odmiene od siebie grupy zadań, powierzając komunikację z warstwą prezentacji właśnie specjalnie do tego wydzielonym obiektom DTO.

Przeciwnicy powiedzą: Zbyt duży nakład pracy, a korzyści nie tak widoczne jak by się można było tego spodziewać.

3) Większa wydajność.

W czasach systemów rozproszonych często warstwy aplikacji znajdują się na różnych maszynach stąd komunikują się poprzez sieć. Komunikacja ta może się odbywać z wykorzystaniem różnych mechanizmów jak WebService (SOAP), .NET Remoting, COM+, itp. Często do pojedynczych widoków w warstwie prezentacji przesyłamy tylko część danych z encji. Nie zawsze encje pokrywają się 1 do 1 z widokami. Zamiast przesyłać poprzez sieć duże obiekty encji biznesowych warto przepakować do obiektów DTO tylko te dane, które faktycznie będą nam potrzebne w widoku.

Przeciwnicy powiedzą: W dzisiejszych czasach wydajność systemów to nie problem, zresztą kto na to zwraca uwagę.

Jak napisałem na początku odpowiedzi jednoznacznej nie ma. Bez dwóch zdań koszty pracy związane ze stosowaniem obiektów DTO są wyższe, no  przynajmniej na początku. Warto rozważyć, przed przystąpieniem do nowego projektu, stosowanie obiektów DTO, co nie oznacza, że w każdym przypadku będzie to trafione rozwiązanie. A więc pytanie „DO or not DO” pozostaje otwarte …