skyANAХоливар-то зачем разводить?Холивар - единственный источник достоверной информации. :-)

МСУАлексей Кпропущено...
REST = SOAP - schema + HTTP only.

И чем тут гордиться?
По Рою Филдингу:

REST надёжность (за счет отсутствия необходимости сохранять информацию о состоянии клиента, которая может быть утеряна);

производительность (за счет использования кэша);

масштабируемость;

прозрачность системы взаимодействия, особенно необходимая для приложений обслуживания сети;

простота интерфейсов;

портативность компонентов;

легкость внесения изменений;

способность эволюционировать, приспосабливаясь к новым требованиям (на примере Всемирной паутины).


Мало?По Алексею К
SOAP надёжность (за счет отсутствия необходимости сохранять информацию о состоянии клиента, которая может быть утеряна);

производительность (за счет использования кэша);

масштабируемость;

прозрачность системы взаимодействия, особенно необходимая для приложений обслуживания сети;

простота интерфейсов;

портативность компонентов;

легкость внесения изменений;

способность эволюционировать, приспосабливаясь к новым требованиям (на примере Всемирной паутины).


МСУАлексей Кпропущено...
Теперь можно серверную логику разместить на клиенте? Я знаю способ лучше:

Логика может быть где угодно, как на сервере приложений, так и на клиенте .Странно.
МСУГлавное, чтобы не базе данных, как это любят делать закоренелые деды процедурщики. Так что твой способ лучше еще раз иллюстрирует весь дикий образ процедурного программирования.Не вижу разницы.
МСУАлексей Кпропущено...
В написании серверной логики на клиенте - да, это может помочь.
Что ты прицепился к этой логике. Какая тебе разница, где она, на сервере или на клиенте? Да и когда обычные фильтры, сортировки и отслеживание изменений уже стали называться "логикой"? На клиенте ты можешь формировать гибкие выборки из Edm модели на сервере, только и всего.Добавилась возможность выстрелить себе в ногу писать логику на клиенте. Почва для статей вроде "Bad practic in OData" блогописателям и курсопроводителям не помешает.
МСУАлексей Кпропущено...
Жертва маркетинга.
Хватит ныть! :)Терпи. :-)
МСУАлексей КХочу знать официальную позицию корпорации по данному вопросу. А то все кричат: "Похороны, похороны..." - а никто не сообщает, где и когда.
Уже давно всё на одате, начиная от сапов, кончая всякими шарепоинтами и CRM-ами. А тебе всё официальщины хочется? Выходи из берлоги, пора уже "уважение" != "признание"

hVosttАлексей КПо Алексею К
пропущено...


Наглость не пропьёшь Читаем: ВикипедияREST (сокр. от англ. Representational State Transfer — «передача репрезентативного состояния») — метод взаимодействия компонентов распределённого приложения в сети Интернет, при котором вызов удаленной процедуры представляет собой обычный HTTP-запрос (обычно GET или POST; такой запрос называют REST-запрос), а необходимые данные передаются в качестве параметров запроса . Этот способ является альтернативой более сложным методам, таким как SOAP, CORBA и RPC.Отсюда делаем вывод, что в, например, SOAP необходимые данные передаются не в качестве параметров запроса? А как же тогда? Что такое "параметр запроса" в понимании автора?
ВикипедияХотя данная концепция лежит в самой основе Всемирной паутины, термин REST был введён Роем Филдингом (англ. Roy Fielding), одним из создателей протокола HTTP, лишь в 2000 году[1]Был написан большой реферат? Да пофиг. Почему название протокола такое странное: протокол передачи гипертекста? Прописная истина "если ты не знаешь как назвать - значит ты не знаешь, что это такое" в действии.
ВикипедияВ своей диссертации в Калифорнийском университете в Ирвайне[2] он подвёл теоретическую основу под метод взаимодействия клиентов и серверов во Всемирной паутине, абстрагировав его и назвав «передачей репрезентативного состояния».Реферат назвали диссертацией, странно, почему Нобелевскую не дали.
ВикипедияФилдинг описал концепцию построения распределённого приложения, при которой каждый запрос (REST-запрос) клиента к серверу содержит в себе исчерпывающую информацию о желаемом ответе сервера (желаемом репрезентативном состоянии), и сервер не обязан сохранять информацию о состоянии клиента («клиентской сессии»).Изобретено колесо disconnected-режим взаимодействия. Браво!

авторВ качестве необходимых условий для построения распределенных REST-приложений Филдинг перечислил следующие:[2]
Клиент-серверная архитектура.
Сервер не обязан сохранять информацию о состоянии клиента.
В каждом запросе клиента должно явно содержаться указание о возможности кэширования ответа и получения ответа из существующего кэша.
Клиент может взаимодействовать не напрямую с сервером, а с произвольным количеством промежуточных узлов. При этом клиент может не знать о существовании промежуточных узлов, за исключением случаев передачи конфиденциальной информации.
Унифицированный программный интерфейс сервера. Филдинг приводил URI в качестве примера формата запросов к серверу, а в качестве примера ответа сервера форматы HTML, XML и JSON, различаемые с использованием идентификаторов MIME.
WCF+SOAP+InstanceContextMode.PerCall соответствует этим требованиям. Получается, что WCF SOAP - это REST ?

skyANAАлексей Кпропущено...
WCF+SOAP+InstanceContextMode.PerCall соответствует этим требованиям. Получается, что WCF SOAP - это REST ?Ну что за баян? Обсуждали же уже.Я не участвовал. Что решили?

skyANAАлексей Кпропущено...
Я не участвовал. Что решили?Участвовал. Это же в твоём топике "Asp.Net vs WCF" было.Там параллельно было несколько дебатов, я не во всех участвовал.

МСУАлексей К, ну ведь красота? http://codearticles.ru/articles/2524

Даже укурившись самой сладкой травой в мире ты не получишь такой концепт в гавносупе. Согласен?Рекурсивно пробежаться по дереву объектов и подписаться на все PropertyChanged - это сложно, да.

А ещё проще, как ни странно, это решается в Knockout в десяток строк кода:


Про REST комментариев не будет? Или согласен, что терминология так себе? :-)

skyANAАлексей КПро REST комментариев не будет? Или согласен, что терминология так себе? :-)REST - это подход, SOAP - это протокол. Сравнивать глупо. Решили сравнивать OData с SOAP.
Подробности смотри в том твоём топике :)

И тут кстати речь про OData, а OData != REST (опять в том топике определились). Так что не начинай заного глупый спор.А я и не спорю. Я публично удивляюсь написанному в википедии:
автор REST (сокр. от англ. Representational State Transfer — «передача репрезентативного состояния») — метод взаимодействия компонентов распределённого приложения в сети Интернет, при котором вызов удаленной процедуры представляет собой обычный HTTP-запрос (обычно GET или POST; такой запрос называют REST-запрос), а необходимые данные передаются в качестве параметров запроса. Этот способ является альтернативой более сложным методам, таким как SOAP , CORBA и RPC.

МСУАлексей КРекурсивно пробежаться по дереву объектов и подписаться на все PropertyChanged - это сложно, да.
Идея топора при незапертой двери в действии
Во-первых, зачем куда-то бегать, если есть нативный функционал в виде честных колбэков. Во-вторых, где ты там в супе собрался бегать? Ну побегал и что? Модели нет, трекера изменений нет, тупая процедурщина да и только. Унылое гумно. Точка.svcutil.exe генерирует INotifyPropertyChanged.

МСУАлексей КА ещё проще, как ни странно, это решается в Knockout в десяток строк кода
То, что ты где-то там побегал, не решает 2 и 3 пункты, о которых я писал выше. Так что беганья эти могут быть только на пустом месте.Все остальное прикручивается легко и непринуждённо. :-)

МСУАлексей Кsvcutil.exe генерирует INotifyPropertyChanged.
И что ты дальше с ними будешь делать? :) Трекера-то нету Готовых решения вагон. Но я, конечно же, напишу это сам за день-два-три, если будет надо. Пока не надо.

Это нужно только в одном случае - сохраняется сложный документ, при сохранении нельзя применить стратегию "удалить всё + добавить всё". Решается сравнением сохраняемого с тем, что в БД.

public static void AttachManyAs<T>(this DbContext ctx, IEnumerable<T> items, Expression<Func<T, bool>> existingItemsFilter)