Служба WCF на основе OData или обычная служба WCF для приложения Silverlight

Я только что начал оценивать, следует ли использовать службы данных wcf, на которые влияет OData, или стандартное приложение службы WCF в качестве основного источника данных для приложений Silverlight. Я хотел бы, чтобы вы думали о том, какой способ лучше в какой ситуации/обстоятельствах. Что легче по проводу, проще в обслуживании и т.д.

То, что я собрал до сих пор, это:

  • Насколько я знаю, в VS2010 нет шаблонов службы данных Wcf, и мне нужно будет сначала создать веб-проект asp.net, а затем добавить службу данных wcf, поэтому это повлияет на то, как я структурирую свои проекты.
  • Службы данных WCF предоставляют фактические имена таблиц через службу. Я еще не знаю, как я могу их назвать, и я не уверен, что это хорошая идея, чтобы мир знал мою структуру таблицы.
  • В стандартной службе wcf мне нужно будет написать запросы linq к классам службы EF или домена на стороне службы, а в службе данных я могу перенести эту логику обработки на клиент.
  • На первый взгляд изучение классов, предоставляемых службами данных wcf, кажется более легким для чтения и понимания, чем классы, предоставляемые EF.

Добавляйте свои мысли по этому поводу..

Спасибо за ваше время.


odata wcf silverlight-4.0
person user20358    schedule 13.11.2010    source источник

Ответы (1)


arrow_upward
5
arrow_downward

В VS2010 нет шаблонов службы данных Wcf, о которых я знаю,

Не шаблон проекта — просто шаблон элемента (для использования внутри веб-сайта или веб-приложения ASP.NET). WCF DataServices очень тесно связаны с HTTP, поэтому они имеют смысл только на веб-сайте/приложении.

Службы данных WCF предоставляют фактические имена таблиц через службу.

НЕТ! По крайней мере, не обязательно. Весь смысл EF заключается в том, что вы можете отделить фактическую физическую структуру вашей базы данных от (концептуальной) модели, которая раскрывается. Вы можете полностью переименовывать сущности, вы можете сопоставлять несколько сущностей с одной таблицей, разделять сущность на несколько таблиц, вы можете опускать атрибуты - все что угодно!

На первый взгляд изучение классов, предоставляемых службами данных wcf, кажется более легким для чтения и понимания, чем классы, предоставляемые EF.

Я сомневаюсь в этом, потому что по умолчанию службы данных WCF будут использовать в качестве основы модель Linq-to-SQL или EF. Вы можете сделать это простым или сложным, как вам нравится.

Использование «обычной» службы WCF позволяет использовать netTcpBinding для гораздо более высокой производительности (благодаря двоичному кодированию сообщений по сравнению с текстовыми сообщениями для других привязок) при использовании приложения Silverlight 4 во внутренней сети компании (не работает для Интернет-сценарии) - это не то, что вы можете сделать с WCF DataServices.

Основное отличие, на мой взгляд, заключается в разнице между SOAP и REST:

  • SOAP (традиционный WCF) ориентирован на методы — вы думаете и проектируете свою систему с точки зрения методов — вещей, которые вы можете делать (GetCustomer, SaveOrder и т. д.)

  • REST (подход WCF DataServices) касается ресурсов, например. у вас есть свои ресурсы и коллекции ресурсов (например, Customers), и вы предоставляете их миру с помощью стандартных глаголов HTTP (GET, POST, PUT, DELETE) вместо отдельных определенных методов, которые вы определяете

Так что оба подхода имеют свои плюсы и минусы. Я думаю, самый важный вопрос: какое приложение вы создаете и на какую пользовательскую аудиторию вы ориентируетесь?

Обновление:

  • для интрасети/внутренних приложений я думаю, что преимущество netTcpBinding (двоичное кодирование) оправдывает использование классической службы WCF - также для приложений с интенсивным использованием данных я лично считаю подход, основанный на методах (GetCustomer, SaveCustomer), более простым в использовании и понимать

  • для общедоступного приложения использование HTTP и обеспечение максимальной совместимости, вероятно, являются вашей главной заботой, поэтому в этом сценарии я бы, вероятно, предпочел службу данных WCF - простые в использовании, простые для понимания URL-адреса для пользователя

person marc_s    schedule 13.11.2010
comment
Спасибо за ответ. Ну, в данный момент я изучаю оба подхода и пытаюсь найти ответ на тот же вопрос. Какой из двух вариантов является лучшим вариантом для какого типа приложения. Тип приложения: 1.) Интранет-приложение с интенсивным использованием данных 2.) Общедоступное интернет-приложение с интенсивным использованием данных - person user20358; 14.11.2010