Найсучасніші найкращі практики Microsoft щодо створення рівня даних .NET? А реальність?

13

Команда розробників, з якою я працюю, незабаром перейде до .NET 4.0, проте бібліотека класів доступу до даних, яку ми використовуємо, все ще використовує ADO.NET «класичний», що означає SqlDataReader , DataTable тощо. Тим часом, схоже, що Microsoft і, ймовірно, весь світ рухається вперед за допомогою Entity Framework і WCF Data Services . У MSDN я не знайшов нічого, що вказувало б, яку з технологій доступу до даних Microsoft вважає найкращою практикою.

Чи має Microsoft перевагу? Який доступ до даних найбільше використовують зараз користувачі? Чи є вагомі причини залишатися з класикою ADO.NET і не переходити на Entity Framework?

c# .net database-development

— Т. Вебстер
джерело

Гарне питання. Один nit: "рівень даних" може бути більш точним терміном. "Рівні" можуть також означати частини розподіленої системи, які можна виконувати на окремих ящиках.

— ажеглов

1

@azheglov, "рівень даних" був моєю першою думкою, але потім я переглянув це, і зрозумів, що перейти з будь-якою термінологією, яку я бачив у MSDN: msdn.microsoft.com/en-us/library/bb384398.aspx . Я погоджуюся, що рівень даних є більш точним.

— Т. Вебстер

Вебстер: дякую, що

— подивилися

4

У моїй фірмі ми використовуємо EF. Це приємна ОРМ, підходить для нашого маленького проекту. Насправді люди використовують EF або NHibernate. Обидві рамки хороші. EF має чудову підтримку MS, і ви можете знайти чудові інструменти в комплекті з Visual Studio. NHibernate вважається кращим, ніж EF, але існує більша "крива навчання", тому ви витратите більше часу на його прийняття.

Я думаю, що якщо ви перебуваєте на "класиці" Ado.Net, спробуйте EF. Створіть простий проект і замініть деякі методи DAL. Перевірте, як він працює і як ви можете керувати / змінювати код. Порівняйте його з простими методами "SqlDataReader" і вирішіть, який краще. Пам’ятайте, що для кожної зміни технології потрібен певний час для прийняття, тому вам доведеться обчислити, чи буде ця зміна корисною для вашої компанії в довгостроковій перспективі.

— Міхал Франк
джерело

5

Моя команда виявляє реальність переходу до EF трохи болісно. Це не тому, що EF поганий чи не корисний, але масштаб перетворення існуючих шарів даних (досить масивний) із сильно типізованих наборів даних, що походять від ADO.Net Framework 2.0 і більше до EF, - це просто велика робота, яка насправді не отримує нам що завгодно. Щодо нових речей, ми все ще досить рвемося, бо всі ми маємо думку та цілі. Для наших проектів Silverlight ми зосереджуємось виключно на послугах EF та RIA, але для веб-проектів (веб-форми та MVC 3) ми використовуємо в першу чергу Linq2Sql.

Ми виявляємо менше головних болів і швидшого розвитку за допомогою Linq2Sql, але я знаю, що Microsoft висуває порядок денний EF (особливо з сервісами WCF та RIA). Linq2Sql нікуди не дінеться, але всі нові іграшки та класні функції будуть зосереджені на EF. Я б сказав, якщо у вас є вибір на початку, EF буде хорошим місцем для початку. Якщо ви вже середній потік, я не знаю, що переключитися буде дуже просто.

— Джоел Етертон
джерело

3

Entity Framework - це кращий шлях. LinqToSql підтримуватиметься та підтримуватиметься, але фокус на розробці спрямований на Entity Framework. Вибір між ADO.NET Entity Framework та LINQ для SQL

— клір2м
джерело

а чим ти зараз користуєшся?

— Т. Вебстер

2

Я думаю , що все використовують linq2sql

— CND

@nCdy: Хоча деякі члени нашої команди вважають Linq2Sql занадто "балаканиною", ми всі вважаємо, що EF автоматично генерує занадто багато непотрібних мотлохів, які L2S просто обходить.

— Джоел Етертон