Уровень DAL: EF 4.0 или обычный уровень доступа к данным с хранимой процедурой

Question

Применение:

Я работаю над одним приложением среднего размера, которое будет использоваться в качестве продукта, нам нужно определиться с уровнем DAL. Пользовательский интерфейс приложения находится в Silverlight, а уровень DAL будет позади уровня обслуживания. Мы также продвигаемся с моделью предметной области, поэтому наши таблицы БД и классы предметной области не имеют одинаковой структуры. Таким образом, такие шаблоны, как Data Mapper и Repository, обязательно войдут в картину.

Мне нужно спроектировать слой DAL с учетом нижеупомянутых факторов в приоритетном порядке

1. Скорость разработки с показателями выше среднего
2. Техническое обслуживание
3. Будущая поддержка и стабильность технологии
4. Производительность

Ограничение:

1) Поскольку нам нужно строго придерживаться Microsoft, мы не можем использовать NHibernate или любой другой ORM, кроме EF 4.0

2) Мы можем использовать любой инструмент для генерации кода (должен быть с открытым исходным кодом или очень дешевый), но он должен генерировать код только в .Net, чтобы не было проблем с лицензированием для каждой копии.

Вопросы

1. Я прочитал так много статей об EF 4.0, с самого начала кажется, что ему все еще не хватает функций из NHibernate, но он значительно лучше, чем EF 1.0

Итак, вы, люди, чувствуете, что мы должны продолжить работу с EF 4.0, или мы должны придерживаться ADO .Net и использовать любой инструмент для генерирования кода, такой как code smith или любой другой, который вам удобнее

2. Также мне нужно ответить на вопросы, например, сколько времени потребуется для переноса приложения с EF 4.0 на ADO .Net, если в будущем мы остановимся на EF 4.0 для некоторых функций или у нас возникнут серьезные проблемы с производительностью.

3. В обратном случае, если мы пойдем дальше и выберем ADO .Net, сколько времени потребуется для перехода к EF 4.0

Наконец, когда я просматривал статью, я обнаружил, что подход, основанный только на коде (с классами POCO), кажется, лучше всего подходит для наших требований, поскольку переключение с одной технологии на другую действительно просто.

Пожалуйста, поделитесь своими мыслями о том же и, пожалуйста, проведите по вышеуказанным вопросам

Answer 1

Использование EF4 сэкономит вам много ручного кодирования - или генерации кода.Это само по себе оправдывает его использование - лучший код и единственный код, который гарантированно не содержит ошибок, - это код, который вам не нужно писать.

EF4 и NHibernate и тому подобное - очень мощные инструменты, которые могутобрабатывать самые требовательные и сложные бизнес-требования - такие как наследование в таблицах базы данных и многое другое.Однако они действительно добавляют некоторые накладные расходы - и их не всегда легко выучить и взять.

Поэтому мой провокационный вопрос будет звучать так: почему бы не использовать Linq-to-SQL ?Если вам нужен только SQL Server в качестве бэкэнда, если ваши сопоставления почти всегда являются отображением 1: 1 между таблицей и классом в вашей доменной модели, это может быть намного проще, чем использование EF4 или NHibernate.

Linq-to-SQL определенно проще и быстрее, чем EF4 - это всего лишь довольно тонкий слой поверх вашей базы данных.Это намного проще, чем изучать NHibernate - не нужно изучать синтаксис грязного отображения, у вас есть поддержка через визуального дизайнера.И это достаточно просто, что вы даже можете войти туда и управлять генерацией кода, используя, например, шаблоны T4 (см. Шаблоны Linq-to-SQL Damien Guard ).

Linq-to-SQL - этоПоддерживается на 100% даже в .NET 4 / VS 2010, так что есть большая вероятность, что он все еще будет в VS2012 (или как будет называться следующий).Таким образом, все эти предсказания о конце света в значительной степени преувеличены - я не буду беспокоиться о том, что это на будущее на секунду.

ОБНОВЛЕНИЕ: Некоторые сравнения производительности между Linq-to-SQL и EF:

• Entity Framework и сравнение производительности Linq-to-SQL
• Взгляд на производительность EF - некоторые сюрпризы
• Entity Framework и LINQ to SQL

В целом, Linq-to-SQL, кажется, имеет преимущество в производительности запросов, но EF, кажется, лучше обновляется.

Answer 2

Откуда вы взяли, что DAL с привязкой к хранимой процедуре - это нормально? Я лично попрощался с ними, как 15 лет назад, и пошел на системы, подобные любому ORM, на рынке (hing: Entity Framework довольно плох по сравнению с такими вещами, как nhibernate). Лично меня всегда очень удивляет, что все, кроме MS "фанаты", ORM - это что-то новое.

Даже с учетом ограничений, которые имеет Entity Framework - это намного лучше, чем все, что вы можете вручную создать с помощью хранимых процедур.

1: обычно от 40% до 60% кода занимаются взаимодействием с базой данных. Это устраняется любой не глупой ORM -> сделать математику.

2: см. 1.

3: хороший вопрос. К сожалению, у MS есть история глупостей в области доступа к данным.

4: скорее всего, такой же, как ваш рукописный - в пределах 5%. К сожалению, ваш анемичный ORM (Entity Framework) не реализует какие-либо действительно интересные функции (кеширование и т. Д.), Поэтому огромные выгоды не ожидаются автоматически.