ADO.NET Entity Framework или ADO.NET

Question

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

Приложение должно быть довольно большим и обслуживать большое количество клиентов, тянущих и обновляющих высокую частоту. изменение данных.

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

Мой план для этого проекта - использовать VS2010 и новую платформу EF4.

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

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

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

• Должен ли я пойти на риск или просто придерживаться старого доброго ADO.NET?

Answer 1

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

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

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

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

Конечно, вы можете вернуться к обычному ADO.NET - но вы действительно хотите снова поиграть с DataTables, DataRows и нетипизированными Row["RowName"] конструкциями ?? РЕАЛЬНО ???

Так что моя рекомендация будет такой:

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

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

Answer 2

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

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

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

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

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

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

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

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

Answer 3

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

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

НТН.