Warstwa abstrakcji dostępu do bazy danych

Witam !

Ostatnio zastanawiam się, czy jest możliwe, aby w projekcie .NET stworzyć taką warstwę abstrakcji, aby zmiana bazy danych mogła być możliwa, bez zmiany w kodzie.

Co do ADO.NET Commands itd to można stworzyć X interfaców i tworzyć dane metody, które zwracają dane wartości, następnie można śmiało podmieniać implementacje interfacu do np. MySQL, MsSQl, reszta aplikacji będzie działała ok.

Zastanawiam się bardziej, czy coś podobnego jest możliwe w ORM-ach. Do EF możemy użyć IObjectSet<klasa> i co prawda możemy wykorzystać wszystkie bazy obsługiwane przez EF, ale nadal jesteśmy skazani na EF.

Czy istnieje takie rozplanowanie aplikacji trójwarstwowej, aby ostatni zabieg był możliwy ? Czyli zamiana ORM z EF na np. Nhibernate.

Czy korzystając z wzorca Repository, można wykonać takie cudo. Chcę powiedzmy, żeby klasy repository (głównie jakieś linq) były niezmienione.

Jeśli kod logiki biznesowej i wyżej będzie operował wyłącznie na interfejsach, a Twoje klasy od repository czy innego data access będą je tylko implementowały, to teoretycznie jest to możliwe.
W praktyce nigdy się z tym nie spotkałem, bo nikogo nie stać na takie zabawy.

somekind to zależy od której strony się patrzy. Klient raczej nie zachce sobie w trakcie użytkowania zmiany bazy np na XML - faktycznie nieopłacalne. Ale czasami ten sam projekt można wdrożyć u rożnych klientów, gdzie sposób przechowywania danych może się różnic. Wtedy bardzo niskim kosztem pisze się samą implementacje DAL.

Uważam, że jeśli tworzymy rozwiązanie, które logikę może mieć elastyczne reguły biznesowe (oparte np. o workflow) to należy od razu stworzyć elastyczne DAL i warstwę prezentacji. Krew mnie zalewa jak widzę w warstwie BL obiekty encyjne ORM'a - wtedy tak naprawdę to mamy g**no a nie osobne warstwy. Równie kuriozalne jak dla mnie jest WCF DataServices, które eksponuje obiekty EF po stronie klienta serwisu...

Nigdy nie tworzyłem czegoś wdrażanego u wielu klientów, ale faktycznie w takim przypadku to może mieć sens.

siema cześc i czołem napisał(a)

Równie kuriozalne jak dla mnie jest WCF DataServices, które eksponuje obiekty EF po stronie klienta serwisu...

Ale nie musi, ani tego nie narzuca. To że komuś tak łatwiej to inna kwestia.

Z uwagi na serwis i utrzymanie takie opieranie warstwy na kilku or mapperach wg nie ma sensu. Stworzenie takiej warstwy dal żeby umiała używać różnych baz ma już sens. Dobry or mapper też obsłuży kilka rodzajów baz danych. Zdaje się że EF nie jest ograniczony do MS SQL Srv, ale używa api ado .net, więc mając odpowiedniego providera do innego rodzaju systemu bazy danych powinno działać (głowy za to nie dam :]).

Elastyczne rozwiązanie, poza możliwością wymiany całej warstwy według mnie ma także szereg innych zalet. Dodawanie nowych obiektów domenowych - kein problem w obu przypadkach, ale usuniecie encji wymaga nieporównywalnie mniej pracy, gdy trzeba ją usunąć w samej DAL zamiast dodatkowego grzebania się w tym w BLL, gdzie wykonywane na niej były jakieś operacje biznesowe. Ale na przykład zmianie ulega reguła biznesowa - np zmiana rodzaju relacji miedzy tabelami, albo dołączenie tabeli, która de facto nie odgrywa roli w realizacji BL i po co ma być dostępna gdzie indziej.

massther: czy my mówimy o tym smaym? Nie mam na myśli zwykłego WCF Services (które według mnie jest genialne) a WCF Data Services, czyli ADO.NET Data Services, które opiera się na założeniach, że system jest scentralizowany pod względem danych - czyli centralna baza danych, a logika realizowana jest realizowana u klienta.

Nie jestem pewien czy zrobienie na tym poziomie elastyczności się opłaci w projekcie i nie wygeneruje sporo kłopotów. Jak już jest gotowa aplikacja to Klient zazwyczaj chce zmieniać zachowanie biznesowe, nie zawsze idzie za tym konieczność zmiany w bazie danych.
A co z GUI, jakimiś integracjami? tak czy tak trzeba by rozbebeszyć kod.

Może lepiej pomyśleć o użyciu jakiegoś silnika BPMS lub jak wspomniał [siema cześc i czołem] BRMS i na tym poziomie pokombinować coś więcej.

Na nietypowy przykład opisu w miarę dynamiczne architektury z zastosowaniem silnika reguł biznesowych możesz tu zerknąć:
http://www.algorithmssystem.com/blog/zastosowanie-silnika-regul-biznesowych-systemie-it
Napisane mało technicznie, ale idea mi się spodobała:)