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

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

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

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

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

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

Xeshu

ОТВЕТЫ

Ответ 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 (среди многих других).

Итак, подведем итог:

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

Ответ 2

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

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

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

Ответ 3

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

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