Философия правильной работы с ORM (Entity Framework)

Question

Я программист баз данных старой школы. И всю свою жизнь я работаю с базой данных через DAL и хранимые процедуры. Теперь у меня есть требование использовать Entity Framework.

Не могли бы вы рассказать мне о своем опыте работы и архитектуре, как с ним работать?

Как я знаю, ORM был создан для программистов, которые не знают выражения SQL. И это единственное преимущество ORM. Я прав?

У меня есть документ по архитектуре, и я не знаю точно, что мне делать с ORM. Я думаю, что мои шаги должны быть: 1) Создать полную базу данных 2) Создайте в модели высокоуровневые сущности, такие как «Цена», которая на самом деле состоит из нескольких таблиц базы данных. 3) Сопоставить таблицы базы данных по сущностям.

Answer 1

ORM делает намного больше, чем просто позволяет не-SQL программистам общаться с базами данных!

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

Таким образом, вы получаете, например, Customer, и вы можете получить доступ к его номеру телефона как строгое свойство:

string customerPhone = MyCustomer.PhoneNumber;

Это намного лучше, чем:

string customerPhone = MyCustomerTable.Rows[5].Column["PhoneNumber"].ToString();

Вы не получаете никакой поддержки от IDE при выполнении этой работы - будьте осторожны с неправильным вводом имени столбца!Вы не узнаете до времени выполнения - либо вы не получите никаких данных, либо получите исключение ... не очень приятно.

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

Таким образом, помимо возможного избавления от необходимости вручную создавать много скучного кода SQL и DAL, ORMтакже дает много преимуществ в использовании данных из базы данных - возможность обнаружения в редакторе кода, безопасность типов и т. д.

Согласен - мысль о том, что ORM генерирует операторы SQL на лету и выполняет их,может быть страшноНо по крайней мере в Entity Framework v4 (.NET 4) Microsoft проделала замечательную работу по оптимизации используемого SQL.Это может быть не идеально в 100% случаев, но в большинстве случаев это намного лучше, чем любой SQL, который написал бы любой неопытный программист SQL ...

Plus: в EF4,если вы действительно хотите и видите необходимость, вы всегда можете определить и использовать свои собственные сохраненные процессы для INSERT, UPDATE, DELETE для любого объекта.

Answer 2

Я могу относиться к вашему чувству желания полностью контролировать ваш SQL.Я сам исследовал использование ORM, и хотя я не могу изложить дело почти так же хорошо, как это сделал marc_s, я подумал, что могу добавить еще пару пунктов.

Я думаю, что смысл ORM заключается в том, чтобысместить акцент с написания кода на SQL и DAL и вместо этого уделить больше внимания бизнес-логике.Вы можете быть более гибкими с помощью инструмента ORM, потому что вам не нужно реорганизовывать свою модель данных или хранимые процедуры каждый раз, когда вы изменяете свою объектную модель.На самом деле ORM, по сути, предоставляет вам уровень абстракции, так что вы можете потенциально вносить изменения в свою схему, не влияя на ваш код, и наоборот.ORM может не всегда генерировать наиболее эффективный SQL, но вы можете выиграть в ускорении разработки.Однако для небольших проектов преимущества ORM могут не стоить дополнительного времени, потраченного на настройку ORM.

Я знаю, что это не отвечает на ваши вопросы.

На ваш 2ndвопрос , мне кажется, что многие разработчики SO, обладающие большим опытом в SQL, все еще выступают за использование и сами используют инструменты ORM, такие как Hibernate, LINQ to SQL и Entity Framework.На самом деле, вам все равно иногда нужно знать SQL, даже если вы используете ORM, и это, как правило, более сложные запросы, поэтому ваша теория о том, что ORM в основном "для программистов, которые не знают SQL" может быть не так.Кроме того, вы получаете кеширование со своего уровня ORM.

Кроме того, Джефф Этвуд, ведущий разработчик SO (этот сайт здесь), утверждает, что он любит SQL (и, держу пари, он очень хорош в этом)и он также старается избегать добавления дополнительных технологий в свой стек, но все же он решил использовать LINQ to SQL для сборки SO. Уже много лет назад он утверждал, что "хранимые процедуры должны рассматриваться как язык ассемблера баз данных: для использования только всамые критические ситуации с производительностью. "

На ваш 1-й вопрос есть еще одна статья из блога Джеффа Этвуда, в которой говорится о различных способах (включая использование ORM) для решенияпроблема несоответствия объектно-реляционного импеданса , которая помогла мне взглянуть на вещи в перспективе.Это также интересно, потому что его мнение об ORM, должно быть, изменилось с тех пор.В статье он сказал, что вы должны «либо отказаться от реляционных баз данных, либо отказаться от объектов», , а также «Я склонен ошибаться на сторонелагерь "база данных как модель". " Но, как я уже сказал, некоторые из пунктов пули помогли мне понять ситуацию.