Sergey ChViPRosДля самой команды EF это выражалось в необходимости поддержки двух разных моделей с одной стороны Code First, с другой — DB/Model First. Подумав, команда решила отказаться от поддержки EDMX в 7-ой версии. Code First only.
совсем охренели
По мне так сразу в ADO.NET писать лучше. А проблемы данных решать непосредственно в MS SQL Server или Oracle

Зачем для серьезных проектов это посредник в виде EF?Быстрый прототип, инвестиции, быстрый старт, а потом избавимся от технического долга в виде EF? :)

А "серъёзные проекты" имеюк какой характер работы с данными? И из каких частей вообще состоят, кроме БД?

Sergey ChhVostt ... Чтобы не писать подобие EF самому, а в серьёзных проектах придётся. Или это будет неподдерживаемое, неповоротливое УГ, классическая лапша, которую тупо даже нельзя протестировать.
Я насмотрелся на столько поделок в виде "классическая лапша" с помощью EF, так что не факт что применение EF кого-либо застрахует от "неповоротливое УГ"

Слой данных должен быть как можно проще, легче и мне нравится иметь полный контроль над ним а не то что потом "builder" собранный кем-то в спальне "настроит" в базе данных...

Сколько мы тратим на создание структуры данных и воплощение ее в базе данных и data layer? От силы 5-10% времени и сделав все в ручную получаешь гарантию 100% что это то, что нужно и оптимизировано под твои 10 миллионов пользователей в день...

Насчёт тестирования - кто Вам мешает в T-SQL or PL/SQL script загнать то, что надо и потом написать test case который будет проверять правильность выполнения... Затраты по времени будут одинаковы, если не меньше...

Хотя это спор ни о чём, если заказчик с промытыми мозгами платит за EF, то почему бы и не EF.

P.S. Хотя для создания prototype который потом пойдет в rubbish bin вполне можно "наваять" с использованием всех новомодных инструментов...Не стоит так утрировать про заказчиков с промытыми мозгами.

Выбор того, или иного решения зависит от характера работы с данными, очевидно же. Ну и от необходимой степени контроля над различными частями системы.

10 миллионов пользователей в день делают что? Один запрос в БД за 10 кб данных? :)

Sergey ChskyANA 10 миллионов пользователей в день делают что? Один запрос в БД за 10 кб данных? :)
Обычная ecommerce система. Товаров порядка 100K и 10 миллионов запросов только на самый крупный web site, а их около 50, так что поболее (http requests по данным Google analytics) будет. Несмотря на то, что данные кэшируются в локальных и распределенных кэшах чтобы облегчить роль SQL Server... Кстати, Data layer является не самым сложный по затратам труда и времени...

Просто мой point был, что в моей практике если надо написать что-то надёжное и быстрое, то лучше это сделать самому, "вылизав" структуру данных и Data layer. То, что генерирует EF - это что-то среднее, в принципе, пригодное для работы (потому как цель EF "объять всё" а это не всегда всех устраивает).

Интересно, а как Вы осуществляете Deploy with EF code first для систем, работающих в режиме 23/7/365 ?Дак мы не используем EF :)

А сколько у вас серверов в ферме? Какова рабочая нагрузка на один веб сервер (количество запросов в секунду)? SQL Serever один?

Вообще я с Вашим поинтом согласен: когда нужна уверенность в каждом узле на пути обработки запроса, то лучше написать самому, потому как досконально разбираться в чужом выйдет дороже и окажется, что под профиль нагрузки не подходит.
И это действительно не долго, в случае с DAL.

Но далеко не у всех миллионы запросов в сутки :)