ViPRosтут кажный пользователь выбирает себе режим работы в идеале, а так админ настраивает систему на с учетом требований к системе
нужна пессимистическая стратегия с блокироками - поставил галочу, нужен лейзи - поставил галочку, нужен пейджинг - поставил галочку,...
По моему Вы сильно много хотите, с таким успехом придем к тому, что юзеров будет проще обучить сиквелам и дать доступ к субд, чем на каждый чих галочку делать. Если система построена на хранимках, то в БД есть таблица с настройками, которые устанавливает админ и которые отвечают за работу всего приложения. У каждого юзера есть свои личные настройки, которые так же хрянятся в БД.

skyANAон считает, что REST - это когда метод Get в ApiController возвращает IQueryable :)
Ты реально тупишь или прикидываешься? А когда метод Get в ApiController возвращает IQueryable этот процесс не подподает под концепцию REST? Не? Никак?

ViPRosда какая нахрен концепция, убогость одна, туфта так сказать
Не могу не согласиться. Одному умнику захотелось очередную диссертацию защитить, вот и стал коней раздувать - если взять http, повернуть задом и наклонить немного то получим... REST!
А потом все копья ломают где REST где нет.
ViPRosесть просто набор адресуемых сущностей через простой путь, даже дерево не запросишь как транзакт, не то что полноценный граф
Даже здесь уже можно срач устроить.

Одни пишут:
http://habrahabr.ru/post/38730/ Отсутствие дополнительных внутренних прослоек означает передачу данных в том же виде, что и сами данные. Т.е. мы не заворачиваем данные в XML , как это делает SOAP и XML-RPC, не используем AMF, как это делает Flash и т.д. Просто отдаем сами данные .

И здесь же:
http://habrahabr.ru/post/38730/ Использование REST для построения Web-сервисов.
Как известно, web-сервис – это приложение работающее в World Wide Web и доступ к которому предоставляется по HTTP-протоколу, а обмен информации идет с помощью формата XML. Следовательно, формат данных передаваемых в теле запроса будет всегда XML.
Ребята с мыло.ру тоже видать не в теме
http://api.mail.ru/docs/reference/rest/ Пример ответа в формате JSON

{
"like": "1",
}

Пример ответа в формате XML

<response_stream_like>
<like>1</like>
</response_stream_like>

Интересно, как можно завернуть данные из той же БД в XML и отдать по http не используя никаких внетренних прослоек?
Вот и задумаетесь, можно сказать что технология OData реализует REST-подход?
Имхо можно, потому что под сферического коня можно завернуть что угодно.

skyANAТвоя проблема в том, что ты их отождествляешь, но когда я тебе намекаю на то, то ты не соглашаешься :) Ну даладно, верь дальше в своё невежество.
Твоя проблема в том, что ты в готову вбил себе хрень, которую я не говорил, еще раз, я нигде не сказал что REST == OData. Но я утверждаю, что технология OData придерживается "конципции" REST! Поэтому эти две аббревиатуры и стояли рядом в одном предложении!

МСУВопрос - чем тебя пугает OData, как способ реализации n-tier для WPF приложений? Конкретно и по существу задал вопрос.
Уже писал:
EDUARD SAPOTSKIОбъясняю. Когда работаешь из того же SL через REST, у тебя линк-запрос на клиенте(приложение SL) транслируется в REST-запрос. На серваке он обратно транслируется в линк-запрос, который в свою очередь EF транслирует в SQL запрос. Т.е. идет цепочка - Linq -> REST -> Linq -> SQL. В итоге получается прям целая четырехзвенка! Вероятность что на каком-то участке что-то отвалится очень высокая, и механизмов контроля всего этого дела фактически нет! Из-за этого возрастает сложность отладки. Но это пол беды. Этот подход мотивирует реализовывать всю логику на клиенте, клиент раздувается, тормозит, елси еще кучу контролов какого телерика юзаешь, то ваще аминь. Но и это фигня. Всю логику на клиент не вытянешь, если приложение более или менее серьезное, начинаешь вытягивать хранимки на уровень REST на серваке. Начинается полный писец! А когда запросов становится дохрена, то очень сложно контролировать их последовательность(когда какой ответ сервака пришел). Вот тогда и начинаешь вспоминать про "заранее обреченный протокол"
Одни из первых греблей по которым прошел при работе с SL & Odata это желание вытянуть всю логику на клиента, OData этому способствует, запросы делаешь линком прямо из SL-приложения, да и в SL все прелести C# & XAML, это тоже подстегивает говнокодить на клиенте, а этого делать низя! SL позволяет реализовать навороченную логику, но надо меру знать или нарвешься на траблы с производительностью, с поддержкой актуальности данных на клиенте, реализация транзакций, отслеживание последовательностей запросов и т.д. Поэтому совет - не перегружай SL клиент логикой! В SL должна быть логика представления(какую когда юзеру менюшку показать и кнопочку) и первичная валидация вводимых данных. Все! Вся основная бизнес-логика должна быть на сервере! А если размещаем всю логику на сервере, то накой нужна OData? Весь ее профит резко уходит в ноль при таком раскладе. Будешь делать туже валидацию, лепить на серваке теже методы да и еще готовняк с ограничениями, OData позволяет через браузер сделать много того чего юзеру делать низя.
Конечно, большинство вопросов через OData решить можно, но нафиг не нужно.