Должен ли я придерживаться Entity Framework?

Я принял EF (из коробки .NET 4.5) в своем новом интернет-приложении.

это приложение действительно включает в себя довольно некоторую операцию над действиями db и включает около 30 или более таблиц.

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

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

1) Включить

Я встречаю функцию Include в части запроса. Многие отсутствующие данные из-за отсутствия включают настройку.

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

2) Проверка

Я принимаю Fluent Validation для этой потребности, поскольку я предпочитаю шаблон посетителя, где не требуется прямого изменения кода для самого кода данных.

но потом я получаю больше проблем, так как я подклассифицирую, мне нужно проверить валидацию, способную уважать простые вещи ООП. Мне это удалось, хотя и сложность и некоторые вещи, которые мне очень не нравятся в ее реализации. Я считаю, что этот вопрос проверки подкласса произошел и в DataAnnotation.

3) Транзакция

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

Я работал с компонентом Enterprise (COM + в .NET, давно давным-давно), и я не могу найти правильную (или отсутствие) реализацию транзакции в EF.

Я все еще работаю над этим...

завершающий)

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

Я собираюсь отказаться от этого EF, переключиться на подход до эры EF, приняв заархивированный, все еще сгенерированный кодом класс таблицы (но не EF или DBML).

Я могу обойтись без SQL LINQ, так как у меня много проблем по сравнению с предыдущей проблемой производительности.

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

Ответ 1

Вы заглянули в Даппера? Dapper - это микро ORM, который очень быстрый. Он был разработан людьми Stackoverflow (Sam Saffron), и они широко используют его на этом сайте по тем причинам, о которых вы говорите, - производительности и скорости. Вот ссылка:

https://github.com/StackExchange/dapper-dot-net.

Мы отбросили EF, и мы используем исключительно Dapper. В сочетании с некоторыми другими сообществами разработаны расширения Dapper, такие как Dapper.SimpleCRUD и Dapper.SimpleCRUD.ModelGenerator, мы можем быстро генерировать POCOs из базы данных, сохраняя при этом все преимущества, которые Dapper имеет над EF. В целом вы будете писать немного больше кода, но скорость Dapper почти эквивалентна использованию ADO.NET SqlDataReader. Здесь ссылка на SimpleCRUD:

https://github.com/ericdc1/Dapper.SimpleCRUD/

Ответ 2

Я согласен, что EF менее полезен, когда вы выходите за рамки определенного этапа

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

Мой 2c (быстрый ответ на очень сложный вопрос):

Напишите SP (да, я знаю), чтобы управлять сбором данных, предоставлять полезные наборы данных для вашего бизнес-уровня и разрешать вставки/обновления в ваши базовые таблицы. Убедитесь, что вы пишете полезный API данных, но не просто пишите CRUD для каждой таблицы. Это бессмысленная трата времени.

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

Наслаждайтесь!

Ни один инструмент не делает все - выберите и выберите, когда возникнут обстоятельства.

Ответ 3

Честно говоря, я несколько лет назад я все же предлагаю любому новичку .net/sql пойти с EF из-за синтаксиса linq, он выглядит сексуально... Но это все об этом. Честно говоря, вы ничего больше не сможете получить от EF.

Я знаю, что соблазн написать С# вместо SQL может показаться очень полезным в начале, но на самом деле это не так. Никакой машинный сервер sql не может бить ручной кусок зверя SQl, который вы в конечном итоге получаете в конце дня:)

Кроме этого, EF просто ест память, которая является памятью и процессором веб-сервера, ну, в большинстве случаев я думаю, но не уверен. Тем не менее, он потребляет больше ресурсов по производительности и по памяти.

И я полностью доволен до ушей тяжелым 20-фунтовым графическим интерфейсом EDMX. +1 фунт за каждый стол:) Потерять так много времени, чтобы сохранить edmx в синхронизации с фактическим DB, и какая причина в конце концов? Кто сказал, что вам нужны все эти красочные значки для ваших столов в VS? Все это есть только для одной и единственной причины - сделать linq-to-entity возможным. К черту это, я просто нахожу оригинальный SQL, выглядящий ничуть не менее приятным или прохладным.

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

Ответ 4

У меня есть свой собственный уровень доступа к данным, созданный с использованием Service ORMlite, и toptensoftware PetaPoco.

ORMlite:

1) Создать таблицу из класса С#, включая отношения, ограничения и т.д. (CodeFirst)

2) Может вставлять, удалять, обновлять и т.д.

example - Создание таблицы: Employee.EnsureTable()

Petapoco:

Провайдеры большой класс оболочки SQL, я использую это вместо linq

для примера: sql.Select( "FirstName, LastName" ). From ( "Employee" ). Где ( "ID = @0", 100).AND( "Active = @0", 1)

Я предпочитаю выше стиль, чем LINQ. Это также поддерживает Joins (Cool right?)

В настоящее время ORM lite не является бесплатным. Но вы можете получить более старую версию, которая бесплатна.

Пример:

//Creating Entity Class

public class Employee:DatabaseEntity<Employee>
{
    //Define properties
}

//DatabaseEntity is my own base class which provides many helper methods from ORM lite and Petapoco, including many static methods eg:EnsureTable()

//Creating Table

Employee.EnsureTable()

//Adding new entity
Employee e=new Employee();
e.FirstName="Chola"
e.LastName="Raja"
e.Active=true
e.Save()

//Find an employee
e=Employee.FirstOrDefault(x=>x.ID==101 && x.Active==true);
//OR
e=Employee.QuerySingle(sql.Select("FirstName,LastName").From("Employee").Where("[email protected]",100).AND("[email protected]",1))

//update
e.LastName="Raja"
e.Save()

//Delete a entity
e.Delete()

//Transaction
e.AssignProject(project1)  //this method could do many operation on many entities using Transaction scope

Примечание: Я не смог извлечь код из моего проекта. Но вы можете создать свой собственный базовый класс в соответствии с вашим требованием