следует использовать Entity Framework вместо raw 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 ,

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

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

Answer 1

В вашем случае я бы выбрал EF, выполнив все это вручную.

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

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

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

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

Смотрите некоторые ресурсы:

• Using Stored Procedures for Insert, Update and Delete in an Entity Data Model
• Practical Entity Framework for C#: Stored Procedures (video)

Answer 2

Вы, кажется, есть сочетание требований и смешивание растворов.

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

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

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

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

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

Answer 3

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

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

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

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

В заключение спросите себя, есть ли смысл создавать объекты с разными конструкторами в среде, и спросите себя, как вы будете их тестировать.