Должен ли я использовать классы Entity Framework, DataSet или Custom?

Question

Мне действительно тяжело. Мне нужно создать «настольное приложение», которое будет использовать WCF в качестве канала связи. Его многоуровневое приложение (DB и сервер приложений одинаковы, клиент проходит через интернет-облако).

Приложение представляет собой небольшую сложность (с точки зрения SQL и кодовой логики), а затем обычные приложения LOB, но концепция одинаков: чтение из базы данных, обновление до DB, обработка параллелизма и т. Д. Моя проблема заключается в том, что теперь с Entity Framework в открытом доступе, я не могу решить, к какому способу работы: Должен ли я использовать Entity Framework, Dataset или Custom Classes.

Как я понимаю, в Entity Framework он будет создавать сопоставление объектов моих таблиц БД с помощью скриптов CRUD. Это хорошо и хорошо для простого CRUD, но в большинстве случаев «Выбрать» является сложным и требует специального SQL. Я понимаю, что я могу использовать хранимые процедуры в EF (я не люблю SP btw, я не знаю, почему, мне нравится код моего SQL в DAL вручную, я чувствую себя более безопасным и удобным таким образом).

С DataSet я буду использовать свои собственные SQL-запросы и заполнить набор данных. С помощью пользовательских классов (объектов для таблиц БД) я заполню свои пользовательские SQL-запросы на этих пользовательских классах (коллекции и списки и т. Д.). Я хочу использовать EF, но я не уверен в развертывании приложения, SQL-код которого я не написал и не вижу в коде. Я что-то упустил.

Любая помощь в этом отношении была бы весьма признательна.

Xeshu

Answer 1

Я согласен с Marc G. 100% - DataSets сосать, особенно в сценарии WCF (они добавляют много накладных расходов для обработки манипуляций с памятью в памяти) - не используйте их. Они подходят для начинающих и двухуровневых настольных приложений в небольшом масштабе, возможно, но я бы не использовал их в серьезном профессиональном приложении.

В принципе, ваш вопрос сводится к тому, как вы преобразовываете свои строки из базы данных в нечто, что вы можете удалять по WCF. Это означает некоторую форму отображения - либо вы делаете это самостоятельно, используя DataReaders, а затем перетаскивая все данные в классы WCF [DataContract] - вы, безусловно, можете это сделать, дает вам окончательный контроль, но это также утомительно, громоздко и подвержено ошибкам.

Или вы разрешите какой-либо готовый ORM справиться с этой грубой работой - возьмите свой выбор из Linq-to-SQL (отличный, простой в использовании, гибкий, но только SQL Server), EF v4 (из Март 2010 года - выглядит очень многообещающим, очень гибким) или любой другой ORM, действительно - что лучше всего подходит вашим потребностям.

Другие серьезные конкуренты в пространстве ORM могут включать Subsonic 3.0 и NHibernate (среди многих других).

Так, чтобы подвести итог:

• забыть о Datasets
• либо у вас есть 100% контроль и отображение между SQL и вашими объектами себя
• вы позволяете некоторые способны ORM справиться с этим (Linq- к SQL, EF v4, Дозвуковые, NHibernate и др) - что один действительно не имеет значения, все, что многое, то это также зависит от личных предпочтений и кодирования стиль

Answer 2

Я не могу выступать наборы данных, особенно в среде SOA, как WCF - это будет работать, но в основном по неправильным причинам. Они просто не переносимы, и ИМО действительно не «работают» над границами служб. Конечно, ИМО они также не работают в большинстве других сценариев; -p

Итак, это зависит от того, сколько сантехники вы хотите сделать. Большинство ORM создадут для вас типы сериализации WCF; лично Я бы использовал LINQ-to-SQL на данный момент; он является более простым и более полным, чем EF, хотя EF 4.0 должен быть намного лучше, чем EF в 3.5sp1. Вы можете использовать собственный TSQL (через ExecuteQuery, который по-прежнему выполняет привязку к объектам), но я стараюсь использовать либо SPROC (для сложных запросов), либо запросы, связанные с LINQ (для простых запросов).

Написание типов самостоятельно тоже хорошо, и вы будете работать с NHibernate и т. Д. Так много вариантов.

Answer 3

в то время как EF работает с WCF и так unds очень многообещающий, вы должны подумать о том, чтобы с ним справиться. Особенно, когда вы делаете некоторые нетривиальные вещи, разработчик в VS2008 больше не может открыть модель, и вам нужно закодировать свою модель в xml.

Также имейте в виду, что EF работает на очень высоком уровне абстракции. Из-за law of leaky abstractions его не все такое блестящее, как оно должно было быть :). В противоположность этому, вам приходится иметь дело с очень сумасшедшими и трудночитаемыми операторами SQL, отправленными в вашу базу данных, когда дело доходит до устранения неполадок/проблем с производительностью.