Является ли Entity Framework более экономичным способом сэкономить немного времени?

Question

Я получил около двух глав на странице «1000+» по фреймворку сущностей, обескуражен и вернулся к старым добрым хранимым процедурам.

Каков консенсус (если таковой имеется) в Entity Framework? Было бы интересно услышать от людей, которые закончили проекты, основанные на EF, чтобы понять, стоит ли им все усилия.

Я немного поработал с шаблонами T4 и нашел способ генерировать свои SPROC и DTO так, как они мне нравятся, не возиться с EF. Я что-то упустил?

Answer 1

Я немного поработал с шаблонами T4 и нашел способ генерировать свои SPROC и DTO так, как они мне нравятся, не возиться с EF.Я что-то упустил?

Не обязательно.Описанный вами процесс является основным аргументом в пользу любого ORM.

Entity Framework предоставляет несколько вещей, которые могут не поддерживаться вашими шаблонами T4:

1. Стандартный для Microsoft способ создания классов данных
2. Возможность масштабирования в большие приложения
3. Возможность поддержки разных хранилищ данных с одним и тем же кодом.
4. Гибкость

EF является частьюбольшей картины, которая включает в себя такие вещи, как встроенная проверка данных, отложенная загрузка, многоуровневый дизайн и тестируемость.Если вы создаете очень маленьких приложений, которые никогда не превратятся в большие приложения, вам могут не понадобиться эти вещи.

Answer 2

Мне лично нравится абстракция и простая интеграция с LINQ, которая возможна с платформой Entity, поскольку ORM вместо непосредственного взаимодействия с SQL-сервером огромна с точки зрения производительности.

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

Answer 3

Существует определенная кривая обучения, когда дело доходит до любого ORM.Это стоит того, чтобы с ним справиться, и вы в конечном итоге доберетесь до некоторых этапов процесса, когда вы действительно увидите преимущества гибкого ORM, такого как EF или NHibernate.

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

Answer 4

Для базовых приложений CRUD Entity Framework или любой приличный ORM сэкономит вам массу времени. Да, есть кривая обучения. Как и в случае с большинством технологий, вы можете использовать то, что знаете, или инвестировать, чтобы узнать что-то, что может быть лучше. ОРМ определенно лучше.

Ваш sproc возвращает считыватель данных или набор данных? Сколько кода вы пишете (с T4 или нет), чтобы перевести этот читатель / набор данных в объектный класс? В конце концов, если вы не используете готовый ORM, вам обычно приходится создавать свой собственный, что является огромной ошибкой.

Как вы решили разделить бизнес-логику (для сценариев без CRUD) между sprocs и классами приложений? С ORM бизнес-логика почти никогда не разделяется, все это относится к классам приложений, которые значительно проще поддерживать.

Я сделал это обоими способами, и T4 оставляет много желательным в качестве решения для уровня данных.

Даже с ORM существуют сценарии (для производительности или чего-либо еще), где вы будете использовать sprocs, и это нормально, но вам никогда не понадобится больше, чем несколько sprocs для базы данных с сотнями таблиц.

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