я должен использовать Entity Framework вместо сырого ADO.NET

Question

Я новичок в CSLA и Entity Framework. Я создаю новое приложение CSLA / Silverlight, которое заменит 12-летнюю систему Win32 C ++. Старая система использует пользовательскую библиотеку бизнес-объектов DCOM и использует ODBC для доступа к SQL Server. Новая система не сразу заменит старую систему - они должны сосуществовать с одной и той же базой данных на долгие годы.

Сначала я подумал, что EF - это путь, так как он самый новый и лучший. После создания небольшой модели EF и только 2 редактируемых корневых объектов CSLA (у меня в конечном итоге появятся сотни объектов, так как в моей БД более 800 таблиц) я серьезно сомневаюсь в использовании EF.

В существующей системе мне много раз нужно было выполнить тонкую настройку производительности запросов, которую я могу выполнить из-за 100% контроля над сгенерированным SQL. Но в EF кажется, что за кулисами происходит так много всего, что я теряю этот контроль. Статья вроде http://toomanylayers.blogspot.com/2009/01/entity-framework-and-linq-to-sql.html не помогает моему впечатлению от EF.

Людям, похоже, нравится EF из-за LINQ to EF, но, поскольку мои критерии передаются между клиентом и сервером в качестве объекта критериев, кажется, что я мог бы так же легко строить запросы без LINQ. В WCF RIA я понимаю, что есть проекция запросов (или что-то подобное), где я могу выполнить клиентский LINQ, который перемещается на сервер перед переводом в реальный SQL, поэтому в этом случае я вижу преимущество EF, но не CSLA .

Если я буду использовать сырой ADO.NET, пожалею ли я о своем решении через 5 лет?

Кто-нибудь еще сделал этот выбор в последнее время и каким путем вы пошли?

Answer 1

В вашем случае, я бы все равно выбрал EF вместо того, чтобы делать все вручную.

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

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

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

• используйте высокую производительность EF для 80% случаев, когда производительность не имеет первостепенного значения
• Точная настройка и ручная работа сохраняют проки для оставшихся 20% и подключают их к EF4

См. Некоторые ресурсы:

• Использование хранимых процедур для вставки, обновления и удаления в модели данных объекта
• Практическая Entity Framework для C #: хранимые процедуры (видео)

Answer 2

У вас, похоже, есть смесь требований и смесь решений.

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

Я согласен с тем, что сказал @ marc_s , вы можете получить лучшее из обоих миров.

Единственное, что я хотел бы сказать, это то, что если это решение будет доступно в течение следующих 5 лет, рассматривали ли вы модульное тестирование?

Есть множество из примеров о том, как настроить это с помощью EF. (Я лично избегаю ADO.Net только потому, что разделение проблем очень сложно для модульных тестов.)

Нет простого решения. Я бы выбрал функцию в вашем проекте, которая заняла бы у вас день или около того. Попробуйте разные методы (raw sql, EF, EF + Stored Procs) и посмотрите, что работает!

Answer 3

Посмотрите на CSLA объективно - вызовите DataPortal и проверьте стек вызовов.

Затем поместите эти классы на сервер сборки CI, который хранит данные времени выполнения и предоставляет график разброса по сериям прогонов.

Далее, посмотрите на код, который создается. Спросите себя, как вы можете использовать такие вещи, как внедрение зависимостей в свете классов, в которых используются статические создатели с защищенными / приватными конструкторами.

Далее, посмотрите, сколько обязанностей берут на себя классы CSLA.

Наконец, спросите себя, имеет ли смысл создавать объекты с разными конструкторами в каждой среде, и спросите себя, как вы будете их тестировать.