Obecne najlepsze praktyki Microsoft w zakresie budowania warstwy danych .NET? A rzeczywistość

13

Zespół programistów, z którym pracuję, wkrótce przejdzie na platformę .NET 4.0, jednak używana przez nas biblioteka klas dostępu do danych nadal używa „klasycznego” ADO.NET, co oznacza SqlDataReader , DataTable i tym podobne. Tymczasem wydaje się, że Microsoft i prawdopodobnie reszta świata idzie do przodu dzięki Entity Framework i WCF Data Services . W witrynie MSDN nie znalazłem niczego, co wskazywałoby, które technologie dostępu do danych Microsoft uważa za najlepsze praktyki.

Czy Microsoft ma preferencje? Z jakiego dostępu do danych korzysta obecnie większość osób? Czy istnieją dobre powody, aby pozostać przy ADO.NET classic i nie przejść do Entity Framework?

c# .net database-development

— T. Webster
źródło

Dobre pytanie. Jedna nitka: „warstwa danych” może być bardziej precyzyjnym terminem. „Poziomy” mogą również oznaczać części systemu rozproszonego, które można uruchomić na osobnych polach.

— azheglov

1

@azheglov, „warstwa danych” była moją pierwszą myślą, ale potem spojrzałem na to i postanowiłem zastosować dowolną terminologię, którą widziałem na MSDN: msdn.microsoft.com/en-us/library/bb384398.aspx . Zgadzam się jednak, że warstwa danych jest bardziej precyzyjna.

— T. Webster

Webster: dziękuję za sprawdzenie i wyjaśnienie

— azheglov,

4

W mojej firmie używamy EF. To ładna ORM, odpowiednia do naszego małego projektu. W rzeczywistości ludzie używają EF lub NHibernate. Oba frameworki są dobre. EF ma doskonałą obsługę MS i możesz znaleźć świetne narzędzia w pakiecie z Visual Studio. NHibernate jest uważany za lepszy niż EF, ale istnieje większa „krzywa uczenia się”, więc poświęcisz jej więcej czasu.

Myślę, że jeśli używasz „klasycznego” Ado.Net, wypróbuj EF. Utwórz prosty projekt i zastąp niektóre metody DAL. Sprawdź, jak to działa i jak możesz zarządzać / modyfikować kod. Porównaj to z prostymi metodami „SqlDataReader” i zdecyduj, który jest lepszy. Pamiętaj, że każda zmiana technologii wymaga czasu na przyjęcie, więc musisz obliczyć, czy ta zmiana będzie korzystna dla Twojej firmy w dłuższej perspektywie.

— Michał Franc
źródło

5

Mój zespół odczuwa ból związany z przejściem na EF. Nie dzieje się tak dlatego, że EF jest zły lub nieprzydatny, ale zakres konwersji naszych istniejących warstw danych (dość masywnych) z silnie typowanych zestawów danych pochodzących z ADO.Net Framework 2.0 na EF to po prostu dużo intensywnej pracy, która tak naprawdę nie zyskuje coś nam. W przypadku nowych rzeczy jesteśmy wciąż dość rozdarci, ponieważ wszyscy mamy opinie i cele. W naszych projektach Silverlight skupiamy się wyłącznie na usługach EF i RIA, ale w projektach internetowych (formularze internetowe i MVC 3) korzystamy przede wszystkim z Linq2Sql.

Za pomocą Linq2Sql znajdujemy mniej problemów i szybszy rozwój, ale wiem, że Microsoft promuje program EF (szczególnie w przypadku usług WCF i RIA). Linq2Sql nigdzie się nie wybiera, ale wszystkie nowe zabawki i fajne funkcje zostaną skoncentrowane na EF. Powiedziałbym, że jeśli masz wcześniej wybór, EF byłby dobrym miejscem do rozpoczęcia. Jeśli jesteś już w połowie strumienia, nie wiem, czy bardzo łatwo będzie się przestawić.

— Joel Etherton
źródło

3

Entity Framework to preferowana metoda. LinqToSql będzie obsługiwany i utrzymywany, ale programowanie koncentruje się na Entity Framework. Wybór między ADO.NET Entity Framework a LINQ to SQL

— klir2m
źródło

a czego obecnie używasz?

— T. Webster

2

Myślę, że każdy używa Linq2Sql

— CND

@nCdy: Podczas gdy niektórzy członkowie naszego zespołu uznali Linq2Sql za zbyt „gadatliwą”, wszyscy jesteśmy zdania, że EF automatycznie generuje zbyt wiele niepotrzebnych śmieci, które L2S omija.

— Joel Etherton