Аргументы использования WCF / OData в качестве уровня доступа вместо EF / L2S / nHibernate напрямую

Question

Мы разрабатываем в основном малопоточные, но узкоспециализированные веб-приложения.Обычно мы используем L2S, EF или nHibernate в качестве уровня доступа, а затем добавляем в него Asp.Net MVC, в котором для обычных операций crud мы напрямую запрашиваем ISession / DataContext, но для более сложных функций / побочных эффектов мы помещаем его в некоторый видуровень обслуживания.

Теперь я подумал о публикации данных через OData (служба данных WCF) и запросе их от контроллеров (или даже из jQuery, когда появляется хороший механизм шаблонов) и публикации операций службы через WCF.сервис (или как пользовательские методы в службе данных WCF?).Какие преимущества / недостатки представляет эта архитектура?

Получу ли я что-нибудь, кроме большей сложности и задержки?Лучшее разделение проблем (или это просто иллюзия)?

Редактировать: Может ли быть хорошей идеей создать полное решение на основе ajax, например, с помощью. WCF RIA Services ?Или человек теряет слишком большую гибкость?Кажется, вы можете полностью отделить свои взгляды от своей логики, тогда, черт возьми, нужно просто написать чистый HTML, даже MVC asp.net не нужен?но я думаю, что возникает много новых проблем?

Answer 1

Не делай этого. Извините, но это глупый, чрезмерно сложный подход. Вы В ОДНОМ ПРОЦЕССЕ, и вы настаиваете на запуске сетевого подключения И кодировании всех передаваемых данных в XML и обратно, а также на запуске через HTTP-соединение с ограниченной семантикой запроса? Не говори никому, что ты даже пытался.

Разделение проблем - это иллюзия: вы заменяете высокооптимизированную модель предметной области упрощенным уровнем данных.

ЭТО СКАЗАЛ: Я люблю OData - отлично. Но это не программная технология, это технология FRONT END, как ASP.NET MVC - просто не для конечного пользователя, а для ДРУГОЙ программы для интеграции в ваши данные. Его следует использовать в аналогичных сценариях и при представлении данных через границы доверия (например, Silverlight - это граница доверия, поскольку запросы могут быть сфальсифицированы).

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

Answer 2

Как упоминает TomTom, вы не хотите оплачивать стоимость обратной связи для OData во время процесса.Если у вас есть прямая видимость вашей базы данных, и это база данных вашего собственного приложения, то нет смысла ставить службы данных WCF в центр.Я бы продолжил использовать один из других вариантов, которые вы упомянули (L2S, EF, nHibernate).

Теперь, если вам нужно предоставить данные через конечную точку http для использования другими приложениями или даже для вашего собственного приложения, если у вас есть некоторый код jQuery на клиенте, которому требуется доступ к данным с сервера, тогда определенноможет помочь конечная точка OData, а WCF Data Services - самый простой способ ее создания.

Answer 3

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

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

Если он создавал приложение на основе различных или неизвестных будущих источников данных, то сервисыслой может объединять, повторно представлять, упрощать и объединять эти службы, даже если большая часть запросов в конечном итоге возвращается к SQL Server в соседней комнате.

Аналогично, если вы создаете приложение массового масштабаПод масштабом я подразумеваю миллионы пользователей, которые ожидают несколько секунд между действиями, а не миллионы сделок с валютой в час, а затем размещают сервисный слой между вашими приложениями, и данные представляют собой общую схему.Масштабируемость Интернета основана на многих небольших HTTP-серверах без сохранения состояния и инфраструктуре кэширования.

В реальной жизни одни и те же запросы выполняются бесчисленное количество раз, люди обновляют страницы или нажимают на одну и ту же ссылку снова и снова.Никто действительно не просит 10-метровые ряды, потому что не много людей могут смотреть на это сразу.Таким образом, работа с небольшими страницами обеспечивает непрерывность потока данных и чередование запросов.У вас также есть возможность ввести общий кэш-память ОЗУ на уровне сервисов или даже базу данных ОЗУ.

Вы можете даже обнаружить, что вам нужно разделить базу данных или разделить ее между SQL и ключом / значением.хранить.Затем вы можете выполнять объединения на промежуточном уровне, масштабировать и выгружать компоненты, требующие большого количества вычислений и соединений, с сервера базы данных.

Правило масштабирования в Интернете заключается в том, что база данных - это ваша горячая точка, и вынужно сделать все возможное, чтобы никто не говорил с ним!Будь то локальный HTTP-кеш на iPad, в прокси-сервере вашего провайдера, в кеше вывода IIS или в кеше Redis, все эти слои помогают распределить нагрузку, облегчают бремя.

Так что, если придет Карлчтобы взять у меня интервью и сказал, что он подумал о том, чтобы поместить слой OData перед своими блоками SQL, мне было бы интересно услышать его рассуждения.

Answer 4

Службы данных WCF и OData поддерживают JSON, поэтому вы можете минимизировать полезную нагрузку, используя это. Кроме того, с помощью WCF Data Services вы можете полностью контролировать свой доступ к данным. Вам не нужно бросать Entity Framework. Вы можете настроить все. Преимущество заключается в том, что структура протокола полностью обрабатывается для вас с помощью служб данных WCF и OData. А использование сервиса от MVC - это просто добавление ссылки на сервис. Службы данных WCF работают на WCF, поэтому у вас есть возможность выполнять другие веб-службы, помимо доставки только по типу OData, что делает его чрезвычайно гибким.

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

Если ваше решение изолированно от одного веб-приложения, тогда встроенный в это приложение слой данных работает хорошо. Но если вам нужно, чтобы другое приложение или процесс попал на уровень данных или разделяемую бизнес-логику, то изучение возможности размещения уровня данных в службе данных WCF того стоит. Например, вы можете написать сценарий PowerShell для вызова метода веб-службы в 2 строки кода. Так что если у вас есть логика домена, которую вы хотите запускать из своего веб-приложения и из командной строки или запланированной задачи, то уровень службы данных WCF может обработать этот сценарий для всех без необходимости дублирования логики или кода.

Множество способов снятия шкуры с кошки. Я использовал оба подхода в бизнес-приложениях и не сказал бы, что одного или другого следует избегать. Они оба работают хорошо и обеспечивают большую ценность, не причиняя вреда.

Answer 5

Чтобы быть справедливым, у этого подхода есть преимущества, которые могут перевесить проблемы производительности, которые по общему признанию огромны. Приложение, созданное таким образом, будет иметь на несколько порядков большую задержку и может стоить в несколько раз больше вычислительных ресурсов для выполнения, чем внутрипроцессное решение.

Как уже было сказано, в сценариях развития, где человеческие ресурсы ограничены, это может работать лучше. Это позволяет быстро нанять подрядчиков для написания новых экранов или совершенно новых приложений очень быстро на любом языке, который им подходит. Разработчики могут получить скорость быстрее, чем запатентованное собственное решение. Больше нет паролей в файлах конфигурации, добавление пользовательского уровня безопасности при необходимости, унифицированная регистрация и аудит, объединение нескольких хранилищ данных в один согласованный ресурс. Если у вас гетерогенная платформа, вам не нужно писать SDK, они уже написаны на многих важных языках. oData очень хорошо работает с MS Excel, что является огромным выигрышем во многих организациях. В зависимости от топологии вашей сети, может быть дешевле и даже быстрее маршрутизировать через Интернет, чем использовать выделенную линию, если вы находитесь в удаленном офисе или за брандмауэром (например, на клиентском сайте, выполняющем демонстрацию) .

Для больших наборов данных накладные расходы на запрос и упаковку становятся менее важными. Для сценариев отчетности, например. Хотя я никогда не проектировал что-то подобное, я могу понять, где может быть полезно, в зависимости от вашей корпоративной культуры и доступных ресурсов, для внутреннего использования конечных точек oData.