Аргументы использования WCF/OData как слой доступа вместо EF/L2S/nHibernate непосредственно
Мы разрабатываем главным образом низкий трафик, но узкоспециализированные веб-приложения. Обычно мы используем L2S, EF или nHibernate как слой доступа, и затем бросает Asp. Сетевой MVC к нему и в котором для нормальных операций грязи мы запрашиваем ISession/DataContext непосредственно, но для более усовершенствованных функций/побочных эффектов мы вставляем его некоторый уровень служб.
Теперь, я был, думают о публикации данных через OData (Услуга передачи данных WCF) и запрос, что от контроллеров (или даже из jQuery, когда хороший движок шаблонов обнаруживается) и публикуют сервисные операции через сервис WCF (или как пользовательские методы для Услуги передачи данных WCF?). Какие преимущества/недостатки делает эту архитектуру позы?
Я получаю что-то кроме более высокой сложности и задержки? Лучшие разделения проблем (или это - просто иллюзия)?
Править: Это может быть хорошая идея создать полный ajax управляемое решение с, например, WCF RIA Services? Или каждый освобождает слишком много гибкости? Чувствует, что можно полностью диспетчеризировать представления от логики затем, heck, нужно смочь просто записать чистый HTML, даже MVC asp.net не должен быть необходим? но я предполагаю, что существует большое новое возникновение задач?
2 ответа
Как упоминает TomTom, вы не хотите оплачивать стоимость обратной петли для OData внутри процесса. Если у вас есть прямая видимость вашей базы данных и это база данных вашего собственного приложения, то нет причин помещать WCF Data Services посередине. Я бы продолжил использовать один из других упомянутых вами вариантов (L2S, EF, nHibernate).
Теперь, если вам нужно предоставить данные через конечную точку http для использования другими приложениями или даже для вашего собственного приложения, если у вас есть код jQuery в клиенте, которому требуется доступ к данным с сервера, то определенно конечная точка OData может помочь, и WCF Data Services - самый простой способ его создать.
Не делай этого. Извините, но это глупый изощренный подход. Вы В ОДНОМ ПРОЦЕССЕ и настаиваете на запуске сетевого подключения и кодировании всех передаваемых данных в XML и обратно, а также запускаете их через HTTP-соединение с ограниченной семантикой запросов? Никому не говорите, что вы даже пытались.
Разделение проблем здесь является иллюзией - вы заменяете высокооптимизированную модель предметной области упрощенным уровнем данных.
СКАЗАНО: Я люблю OData - отлично. Но это не программная технология, это технология FRONT END, такая как ASP.NET MVC - только не для конечного пользователя, а для ДРУГОЙ программы, которая может интегрироваться в ваши данные. Его следует использовать в аналогичных сценариях и при раскрытии данных через границы доверия (например, Silverlight - это граница доверия, поскольку запросы могут быть подделаны).
Он НЕ оптимизирован для замены в процессе высокопроизводительных уровней времени выполнения приложений, таких как NHibernate.