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

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

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

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

Edit: Может быть хорошей идеей создать полное решение, управляемое ajax, например. Услуги WCF RIA? Или сделать слишком много гибкости? Чувствует, что вы можете полностью отсылать свои взгляды из своей логики, тогда, черт возьми, нужно иметь возможность просто писать чистый HTML, даже не нужен ASP.NET MVC? но я предполагаю, что возникает много новых проблем?

Ответ 1

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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

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

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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