ADO.NET Entity Framework или ADO.NET

Я начинаю новый проект, основанный на ASP.NET и Windows server.

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

Я ранее создавал проекты с Linq-to-Sql или с Ado.Net.

мой план для этого проекта, чтобы использовать VS2010 и новая структура EF4.

  • Это буду рад услышать другие параметры программистов о разработке с Entity Framework

  • плюсы и минусы от предыдущих опыт?

  • Как вы думаете, EF4 готов к производство?

  • должен ли я рисковать или просто придерживаться старого доброго ADO.NET?
7
ado.net asp.net entity-framework

3 ответов

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

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

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

но это стоит-эти дополнительные слои влияют на производительность, сложность, ремонтопригодность. Если вам нужны эти функции, вы будете счастлив заплатить эту цену, без вопросов. Но тебе это нужно??

конечно, вы можете вернуться к прямой ADO.NET -но вы действительно хотите возиться с DataTables, DataRows и untyped Row["RowName"] снова создает?? Неужели???

поэтому моя рекомендация будет такая:

  • если вам нужен только SQL Server в качестве бэкэнда
  • если у вас есть довольно простое и простое сопоставление одной таблицы базы данных с одним объектом сущности в вашем модель

затем используйте Linq-to-SQL ! Почему бы и нет?? Он по - прежнему полностью поддерживается Microsoft в .NET 4-черт, они даже сделали исправлены ошибки и добавлено несколько биты и куски - это быстро, это эффективно, это худой и средний - так почему бы и нет??

6

мой совет-использовать оба. Сначала я думал, что буду использовать только linq to sql и никогда не касаться ado.net когда-либо снова ( что сделало меня счастливым lol).

теперь я использую оба, потому что некоторые вещи linq to sql(и любой ORM, как EF) не могут сделать. Мне пришлось сделать несколько массовых вставок, и я сделал это сначала с linq to sql и сделать 500 записей, это заняло 6 минут(2 минуты для правил проверки rest вставлялся в БД).

Я изменил его на SQL bulk copy, и теперь он до 2min и 4 секунд(4 секунды, чтобы сделать все вставки)

но, как сказал marc_s, я действительно не хотел возиться с DataTables, DataRows и нетипизированной строкой["RowName"].

скажем, моя таблица была длиной 10 столбцов и называлась таблицей A. Я использовал linq to sql и сделал таблицу объектом класса( new TableA()) и заполнил ее данными. Затем я передал бы этот объект методу, который создал datarow.

таким образом, linq to sql сэкономил мне некоторое время, потому что я, вероятно, сделали класс, так как я бы не хотел передавать 10 параметров в метод, который делает строку данных. Я также чувствую, что это дает немного типичности, поскольку вы должны передать правильный объект, чтобы использовать этот метод, поэтому меньше шансов передать неправильные данные.

наконец, вы все еще можете использовать linq to sql для вызова хранимых процедур, и это похоже на одну строку кода.

поэтому я бы использовал оба, когда вы заметите, что linq to sql (или в вашем случае EF) медленный, а затем просто напишите SP и вызовите его через EF. Если вам нужно сделать прямо ado.net возможно, вы можете использовать EF для большей части кода (так что вы можете хотя бы работать с объектами) и только для этой небольшой части ado.net вроде того, что я сделал с массовой копией sql.

2

EF 4 теперь больше похож на LINQ to SQL, в хорошем смысле; он имеет ключи FK прямо в объекте, имеет методы add прямо в наборах объектов и множество других приятных функций. Дизайнер значительно улучшен, и основным плюсом является то, что он работает с SQL и Oracle, и, возможно, некоторые другие (если поставщик поддерживает его) вместо LINQ to SQL только с SQL Server.

EF-это будущее; ADO.NET data services-это веб-сервис, который поддерживает POCO и T4 генерация, и любые новые функции будут поддерживать это (LINQ to SQL-это только обслуживание, и наборы данных больше не будут получать никаких изменений).

HTH.

0