EntityFramework VS pure Ado.Net

EF является настолько широко используемым персоналом, но я не понимаю, как его использовать. Я встретил много проблем с ef в разных проектах с разными подходами. Поэтому некоторые вопросы собрались у меня в голове. И ответы заставляют меня использовать чистый ado.net с хранимыми процедурами. Итак, вопросы:

Как работать с EF в n-уровневом приложении? Например, у нас есть DAL с EF. Я видел много статей и проектов, которые использовали репозиторий, шаблоны unitofwork как своего рода абстракцию для EF. Я думаю, что такой подход убивает большинство преимуществ, которые увеличивают скорость развития и приводят к нескольким вещам:
- переназначение нагрузки EF приводит к некоторому DTO, который убивает производительность (вызовите некоторый выбор, чтобы получить данные таблицы - первый цикл, второй результат цикла - к некоторому составному типу, сгенерированному ef, next-filter сопоставленные данные с использованием linq и, наконец, сопоставьте его с некоторыми DTO). Точно переназначение в DTO является убийцей одного из самых больших преимуществ efs.
  или
- приводит к сильным связям между EF (и версией) и приложением. Это будет что-то вроде двухуровневого приложения с dal и презентацией с bll или dal с bll и презентацией. Думаю, это не лучшая практика. И тот же процесс загрузки, что и у предыдущей вещи, кроме картографирования, поэтому снова возникла проблема с производительностью. Мы могли бы попытаться использовать EF как DAL без какой-либо абстракции под ними. Но мы получим аналогичные проблемы каким-то другим способом.
Должен ли я использовать один контекст для каждого приложения \thread\atomic? Использование подхода - один контекст для каждого приложения\поток может немного увеличить производительность и возможности для вызова свойств навигации, но мы сталкиваемся с другой проблемой - обновляем этот контекст и увеличиваем загруженные данные в контексте, также я не уверен в concurrency с одним dbcontext per приложение\нить. Использование контекста за операцию приведет к переназначению результатов в наши DTO. Итак, вы видите, что мы снова вернулись к вопросу №1.
Можем ли мы попытаться использовать только EF + SP? Снова у нас есть вопросы из предыдущих вопросов. В чем причина использования ef, если большая часть функций не будет использоваться?

Итак, да, EF отлично подходит для запуска проекта. Это так удобно, когда у нас мало экранов и красных операций. Но что дальше?

Весь этот текст - это просто несортированные мысли. Я знаю, что чистый ado.net приведет к другим вызовам. Итак, что вы думаете об этой теме?

Ответ 1

Следуя соглашениям об именах, вы обнаружите, что это называется: ADO.NET Entity Framework, что означает, что Entity Framework сидит поверх ADO.NET, поэтому он не может быть быстрее, он может выполнять оба в равное время, но посмотрим на EF:

Вы больше не будете застревать в письменных запросах, не имея никаких подсказок о том, собирается ли что-то писать, или нет.
Это заставляет вас полагаться на С# или ваш любимый язык .NET при написании собственных ограничений данных, которые вы хотите принять от целевого пользователя непосредственно внутри классов модели.

Наконец: EF и LINQ дают много возможностей для поддержки ваших приложений позже.

В Entity Framework есть три разные модели: сначала модель, база данных First и Code First, каждая из которых знакома.

- Точка о том, что при перепрограммировании происходит переполнение, потому что в первом запуске EF загружает метаданные в память, и это занимает много времени, поскольку оно создает представление модели в виде памяти из файла edmx.

Ответ 2

ADO. Net - это объектно-ориентированная среда, позволяющая взаимодействовать с системой баз данных (SQL, Oracle и т.д.). Entity Framework - это техника манипулирования данными в базах данных (сбор запросов (инертное имя таблицы, выберите * из этого)). это используется с LINQ.

Ответ 3

ADO.NET обеспечивает постоянный доступ к источникам данных, таким как SQL Server и XML, а также к источникам данных, предоставляемым через OLE DB и ODBC. Пользовательские приложения для обмена данными могут использовать ADO.NET для подключения к этим источникам данных, а также для извлечения, обработки и обновления содержащихся в них данных.

Entity Framework 6 (EF6) - это проверенный объектно-реляционный картограф (O/RM) для .NET с многолетним опытом разработки и стабилизации. ORM как EF имеет следующее преимущество

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

Это устраняет необходимость в повторяющемся коде SQL и обеспечивает много преимуществ для скорости разработки.

Предотвращает написание ручных SQL-запросов; & Амп; еще много..

В n-уровневом приложении зависит от объема данных, обрабатываемых вашим приложением и управляемых вашей базой данных. Насколько я знаю, DTO не убивает производительность. Они являются контейнером данных для перемещения данных между слоями и используются только для передачи данных и не содержат никакой бизнес-логики. В основном они используются в классах обслуживания. См. DTO.
Один DBContext - это всегда лучшая практика.
Насколько мне известно, такой комбинации EF + SP (хранимая процедура) не существует. Если вы хотите использовать ORM, например, EF и SP, попробуйте микро-ORM, такие как Dapper, BLToolkit и т.д. Он создан для этой цели и, черт возьми, намного быстрее, чем EF. Вот хорошая статья о Dapper ORM.

Вот связанная тема на похожую тему: В чем разница между orm и ADO.net?