ReSQL.ru
     
powered by simpleCommunicator - 2.0.50     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / ASP.NET [игнор отключен] [закрыт для гостей] / Asp.Net vs WCF
25 сообщений из 380, страница 8 из 16
  8  все
Asp.Net vs WCF
    #38790948
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
МСУАлексей Кпропущено...
И вообще, IQueryable - это специфичная дотнетная возможность. Как оно может претендовать на кроссплатформенный кроссязыковой стандарт?
Это ты спроси у консорциума OASIS, а не у меня.Там есть у кого спрашивать? Уровень идиотизма на планете в последнее время просто зашкаливает...
МСУДа и причем тут IQueryable? Сервис OData на .NET, клиенты могут быть любые. И им не нужны IQueryable. В .NET клиенте может появиться IQueryable, если ты используешь это https://www.nuget.org/packages/Microsoft.OData.Client
А если дергать OData сервис через обычный HttpClient, то никаких IQueryable.Можно-то можно, но какой от этого профит на других платформах? IQueryable в них нету. Какой мне профит от ОДата в JS? Стандартные имена параметров, чтобы на них натянуть какой-нибудь ДатаГрид из KendoUI? Мне это не надо...

Получется:
1. В кроссплатформенных интеграциях ОДата не нужен.
2. Для внутренних взаимодействий нужность ОДата тоже под сомнением.

Офигенная технология!
...
Рейтинг: 0 / 0
29.10.2014, 16:22
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38790953
Фотография Диез
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Диез
Участник
МСУАлексей Кпропущено...
И вообще, IQueryable - это специфичная дотнетная возможность. Как оно может претендовать на кроссплатформенный кроссязыковой стандарт?
Это ты спроси у консорциума OASIS, а не у меня. Да и причем тут IQueryable? Сервис OData на .NET, клиенты могут быть любые. И им не нужны IQueryable. В .NET клиенте может появиться IQueryable, если ты используешь это https://www.nuget.org/packages/Microsoft.OData.Client
А если дергать OData сервис через обычный HttpClient, то никаких IQueryable.

Если дергать через HTTP, то исчезают все преимущества кодогенерации => строгой типизации. Лесом :)

А вот вижу пример вызова OData-службы из Java:

Код: java
1.
 List<OEntity> Keywords = client.getEntities("Keywords").filter("(PublicationId eq 17) and (TaxonomyId eq 305)").execute().toList();



Опять же, в компайл-тайме никаких проверок.

В-общем, в корпоративе не взлетит. По крайней мере, не в ближайшее время...
...
Рейтинг: 0 / 0
29.10.2014, 16:24
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38790965
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
МСУАлексей КПартнёров много. Там дикое переплетение вебсервисов различной сложности, написанных неизвестно кем, неизвестно на чём, неизвестно когда, неизвестно зачем.
Ага, то есть льём дальше гавно в навозную бочку? Я понял твою философию.

Алексей КВ документации контракт сервиса как будем описывать? Ссылка из технического задания в туда будет смотреться достаточно глупо. :-)
https://developers.facebook.com/docs/javascript/reference/FB.api Офигенно! Чтобы потом звонили: "Посмотрите наши JSON пакеты, не понятно, почему ваш сервер их не принимает". Было уже, проходили. В случае с SOAP все неудачники отсылаются к стандарту. В итоге коллеги открывают для себя кодогенерацию и всё налаживается.
МСУАлексей КБывают нормальные партнёры?
Бывают.Видимо, на какой-то другой планете и в другое время.
МСУАлексей Кпропущено...
И такое бывает.
Ну от идиотов никто не застрахован. Тут даже SOAP не поможет.Говорю же - помогает.
МСУАлексей КВ WSDL любую модель не описать, да? :-)
В WSDL нельзя описать модель, это процедурный протокол. Методология разработки в WDSL сервисно-ориентированная, в REST- ресурсно-ориентированная. Два полярных знаменателя.ООП-модель происходящего в обоих случаях одинаковая. Есть классы сервисов, содержащие логику, и есть DTO, содержащие данные. Сервисы и DTO могут наследоваться. DTO могут инкапсулироваться. Сервисы могут иметь полиморфизм. ОДата всего лишь добавляет стандартные интерфейсы для сервисов, не более того.
МСУАлексей КНекоторые считают, что IQueryable не должен покидать рамки репозитария, а ты предлагаешь тащить его на клиента. Это жесть просто, учитывая тот факт, что задачи вроде пэйджинга прекрасно решаются банальным ООП-наследованием. Никакие "новые технологии" тут не нужны.
Причем тут OData? Делай свой репозитарий, в котором внутри будешь использовать OData и IQueryable, а на выходе отдавать IEnumerable. Какие-то глупости ты пишешь...ОДата используется для межпроцессного взаимодействия. Как я могу: "Делай свой репозитарий, в котором внутри будешь использовать OData"? Предполагаю, что мы тут друг друга не понимаем. Ничего страшного.
...
Рейтинг: 0 / 0
29.10.2014, 16:34
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38790976
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Алексей КМожно-то можно, но какой от этого профит на других платформах? IQueryable в них нету. Какой мне профит от ОДата в JS? Стандартные имена параметров, чтобы на них натянуть какой-нибудь ДатаГрид из KendoUI? Мне это не надо...

Получется:
1. В кроссплатформенных интеграциях ОДата не нужен.
2. Для внутренних взаимодействий нужность ОДата тоже под сомнением.

Офигенная технология! Гы... А как ты SOAP Envelope в JS собираешь?

Olingo OData Client for JavaScript
Breeze.js

OData Libraries
...
Рейтинг: 0 / 0
29.10.2014, 16:40
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791000
Фотография EDUARD SAPOTSKI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EDUARD SAPOTSKI
Участник
МСУТы же сам определяешь в ODataConventionModelBuilder, какие таблицы будут доступны, какие поля можно вообще скрыть и многое другое. ACL можно подключить, вообщем всё гибко конфигурится. Это плохо? Мне всегда казалось, что это очень хорошо. Не нужно изобретать велосипед.

Вот тебе классический OData CRUD контроллер над сущностью в двумя ключами, минимум кода - максимум возможностей на клиенте для выборок, фильтров, условий, вычислений. Это плохо? Да это просто чудесно, SOAP'у такого и не снилось! Нужно где-то что-то ограничить, проанализировать OData параметры, всё это делается на один чих. Что тебя смущает?
Давай спустимся с небес на землю грешную. Есть ООО "Рога и копыта", есть таблица категорий и таблица продукции, клиентам А и В должна быть предоставлена вся инфа о продукции кроме категории "интимные принадлежности", клиенту С только нужны интимные принадлежности и матрацы. Директор может менять любые цены, бухгалтерша Иванова специалист по интиму, Петрова имеет доступ ко всему остальному. Выдавать клиентам должно не больше 100 записей только с продукцией которая есть на складе. И конечно хакер виртуозно владеющий GET запросами не должен узнать ничего лишнего!
Удиви реализацией на OData и сравним с реализацией на SOAP
...
Рейтинг: 0 / 0
29.10.2014, 17:02
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791015
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
ДиезЕсли дергать через HTTP, то исчезают все преимущества кодогенерации => строгой типизации. Лесом :)
А не всем нужна кодогенерация. Более того, всем она не нужна. Написал или сгенерил 10 классов руками на основе json, примапил их к выхлопу и готово.

ДиезА вот вижу пример вызова OData-службы из Java:

Код: java
1.
 List<OEntity> Keywords = client.getEntities("Keywords").filter("(PublicationId eq 17) and (TaxonomyId eq 305)").execute().toList();



Опять же, в компайл-тайме никаких проверок.

В-общем, в корпоративе не взлетит. По крайней мере, не в ближайшее время...
java всегда отличалась унынием: вот тебе на .NET

Код: c#
1.
var query = api.Products.Expand(p => p.Category).Expand(p => p.Category.CategoryType).Where(p => p.Name.Contains("Бублик") && p.ProductId > 100);
...
Рейтинг: 0 / 0
29.10.2014, 17:11
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791020
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
EDUARD SAPOTSKIМСУТы же сам определяешь в ODataConventionModelBuilder, какие таблицы будут доступны, какие поля можно вообще скрыть и многое другое. ACL можно подключить, вообщем всё гибко конфигурится. Это плохо? Мне всегда казалось, что это очень хорошо. Не нужно изобретать велосипед.

Вот тебе классический OData CRUD контроллер над сущностью в двумя ключами, минимум кода - максимум возможностей на клиенте для выборок, фильтров, условий, вычислений. Это плохо? Да это просто чудесно, SOAP'у такого и не снилось! Нужно где-то что-то ограничить, проанализировать OData параметры, всё это делается на один чих. Что тебя смущает?
Давай спустимся с небес на землю грешную. Есть ООО "Рога и копыта", есть таблица категорий и таблица продукции, клиентам А и В должна быть предоставлена вся инфа о продукции кроме категории "интимные принадлежности", клиенту С только нужны интимные принадлежности и матрацы. Директор может менять любые цены, бухгалтерша Иванова специалист по интиму, Петрова имеет доступ ко всему остальному. Выдавать клиентам должно не больше 100 записей только с продукцией которая есть на складе. И конечно хакер виртуозно владеющий GET запросами не должен узнать ничего лишнего!
Удиви реализацией на OData и сравним с реализацией на SOAP А смысл сравнивать?

Наш абрикос официально trusted by 14,182 small associations, clubs, nonprofits. До фига рогов и копыт, не правда-ли?

В каждой такой некомерческой организации есть свои "директор", "бухгалтерша Иванова", "Петрова" со своими правами и "клиенты".
Данные всех организаций лежат в одной базе.

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

А ссылку на описание я тебе давал. Иди и сравнивай.
...
Рейтинг: 0 / 0
29.10.2014, 17:15
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791022
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
Алексей КТам есть у кого спрашивать? Уровень идиотизма на планете в последнее время просто зашкаливает...
А там нет у кого спрашивать? Ну про уровень идиотизма давай не будем. Если есть в чем обвинить, выкладывай. А так это всё пук в воздух.

Алексей КМожно-то можно, но какой от этого профит на других платформах? IQueryable в них нету. Какой мне профит от ОДата в JS? Стандартные имена параметров, чтобы на них натянуть какой-нибудь ДатаГрид из KendoUI? Мне это не надо...
А какой профит тебе от SOAP на других платформах? Да и это проблемы платформы, есть ли там IQueryable или нету. А профит от одаты на js самый прямой, честный REST и только. Да и я тебе уже говорил про js, твоя архитектура - это худшее, что можно взять от MVC. На помойку.

Алексей КПолучется:
1. В кроссплатформенных интеграциях ОДата не нужен.
2. Для внутренних взаимодействий нужность ОДата тоже под сомнением.

Офигенная технология!
Вот и получаем:
1. В кроссплатформенных интеграциях ОДата будет использоваться как обычный REST трансфер. Зато для .NET решений открывается лес возможностей.
2. Для внутренних приложений - то, что доктор прописал.
...
Рейтинг: 0 / 0
29.10.2014, 17:15
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791030
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
Алексей КОфигенно! Чтобы потом звонили: "Посмотрите наши JSON пакеты, не понятно, почему ваш сервер их не принимает". Было уже, проходили. В случае с SOAP все неудачники отсылаются к стандарту. В итоге коллеги открывают для себя кодогенерацию и всё налаживается.
Так весь мир работает, есть сервис, есть дока, есть сообщение об ошибке. В 99.9% случаев этого достаточно. Не нужно кривые административные проблемы и неумение поддерживать решения перекладывать на OData. Она тут непричем.

Алексей КВидимо, на какой-то другой планете и в другое время.
А может ты сам с другой планеты? Вопрос однако :)

Алексей КМСУпропущено...
Ну от идиотов никто не застрахован. Тут даже SOAP не поможет.Говорю же - помогает.
Чем? Искуственный интеллект в SOAP?

Алексей КООП-модель происходящего в обоих случаях одинаковая. Есть классы сервисов, содержащие логику, и есть DTO, содержащие данные. Сервисы и DTO могут наследоваться. DTO могут инкапсулироваться. Сервисы могут иметь полиморфизм. ОДата всего лишь добавляет стандартные интерфейсы для сервисов, не более того.
Да нахрен мне твои DTO не нужны, я отдаю в OData сразу готовые классы по edmx модели. И они же генерятся на клиенте. За пару кликов - чистое приложение.

Алексей КОДата используется для межпроцессного взаимодействия. Как я могу: "Делай свой репозитарий, в котором внутри будешь использовать OData"? Предполагаю, что мы тут друг друга не понимаем. Ничего страшного.
Ты разницу понимаешь между OData и OData клиентом? :) Вижу, что не совсем, от этого все сложности.
...
Рейтинг: 0 / 0
29.10.2014, 17:20
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791035
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
EDUARD SAPOTSKIДавай спустимся с небес на землю грешную. Есть ООО "Рога и копыта", есть таблица категорий и таблица продукции, клиентам А и В должна быть предоставлена вся инфа о продукции кроме категории "интимные принадлежности", клиенту С только нужны интимные принадлежности и матрацы. Директор может менять любые цены, бухгалтерша Иванова специалист по интиму, Петрова имеет доступ ко всему остальному. Выдавать клиентам должно не больше 100 записей только с продукцией которая есть на складе. И конечно хакер виртуозно владеющий GET запросами не должен узнать ничего лишнего!
Удиви реализацией на OData и сравним с реализацией на SOAP
Задача так же решается, как в SOAP. Та же бизнес логика в контроллере. Какие проблемы? Есть ACL, есть роли, есть пользователи, есть анализ продуктов, есть ограничение выборки результата. По поводу менять цены - это уже PATCH запрос, в нем пишем анализ, какой пользователь, можно ли менять, если нельзя, пробрасываем исключение. Всё как в детском саду.
...
Рейтинг: 0 / 0
29.10.2014, 17:23
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791038
Фотография EDUARD SAPOTSKI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EDUARD SAPOTSKI
Участник
skyANAА ссылку на описание я тебе давал. Иди и сравнивай.
Да мне нафиг твое описание не нужно, я прекрасно понимаю что на OData это сделать можно! Вопрос - какой ценой?! Прекрасно представляю какой говнокод получается на практических задачах, тонны атрибутов, валидаторов и прочих левых приблуд. На SOAP в методах все чисто чинно и прозрачно. В этом и профит!
...
Рейтинг: 0 / 0
29.10.2014, 17:24
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791044
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
EDUARD SAPOTSKIskyANAА ссылку на описание я тебе давал. Иди и сравнивай.
Да мне нафиг твое описание не нужно, я прекрасно понимаю что на OData это сделать можно! Вопрос - какой ценой?! Прекрасно представляю какой говнокод получается на практических задачах, тонны атрибутов, валидаторов и прочих левых приблуд. На SOAP в методах все чисто чинно и прозрачно. В этом и профит! Смешно. Покажи мне реализацию настраиваемого фильтра, а?
...
Рейтинг: 0 / 0
29.10.2014, 17:30
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791046
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Хочешь сравнить SOAP с OData, так давай, покажи!
...
Рейтинг: 0 / 0
29.10.2014, 17:30
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791051
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
EDUARD SAPOTSKIskyANAА ссылку на описание я тебе давал. Иди и сравнивай.
Да мне нафиг твое описание не нужно, я прекрасно понимаю что на OData это сделать можно! Вопрос - какой ценой?! Прекрасно представляю какой говнокод получается на практических задачах, тонны атрибутов, валидаторов и прочих левых приблуд. На SOAP в методах все чисто чинно и прозрачно. В этом и профит!
Ну что опять за бред? Методы OData контроллеров - такие же .NET методы, как и в веб сервисах. Там можно так же писать свою логику, анализ, усечение выборки и всё остальное.
...
Рейтинг: 0 / 0
29.10.2014, 17:33
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791055
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
EDUARD SAPOTSKI, сколько раз мне нужно это повторить? odata actions, transient actions, functions] http://www.asp.net/web-api/overview/odata-support-in-aspnet-web-api/odata-v4/odata-actions-and-functions
...
Рейтинг: 0 / 0
29.10.2014, 17:36
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791056
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
EDUARD SAPOTSKI, сколько раз мне нужно это повторить? odata actions, transient actions, functions
...
Рейтинг: 0 / 0
29.10.2014, 17:37
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791059
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
skyANAАлексей КМожно-то можно, но какой от этого профит на других платформах? IQueryable в них нету. Какой мне профит от ОДата в JS? Стандартные имена параметров, чтобы на них натянуть какой-нибудь ДатаГрид из KendoUI? Мне это не надо...

Получется:
1. В кроссплатформенных интеграциях ОДата не нужен.
2. Для внутренних взаимодействий нужность ОДата тоже под сомнением.

Офигенная технология! Гы... А как ты SOAP Envelope в JS собираешь? Я не хожу в SOAP из JS. Там речь шла про REST + OData.
skyANA Olingo OData Client for JavaScript
Breeze.js

OData Libraries Да зачем это всё надо? Для локальных web-потребностей мне WebAPI + JSON хватает.
...
Рейтинг: 0 / 0
29.10.2014, 17:39
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791066
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
МСУАлексей КТам есть у кого спрашивать? Уровень идиотизма на планете в последнее время просто зашкаливает...
А там нет у кого спрашивать? Ну про уровень идиотизма давай не будем. Если есть в чем обвинить, выкладывай. А так это всё пук в воздух.Прямо не знаю с чего начать. Тема глобального идиотизма достойна отдельного топика.

МСУАлексей КМожно-то можно, но какой от этого профит на других платформах? IQueryable в них нету. Какой мне профит от ОДата в JS? Стандартные имена параметров, чтобы на них натянуть какой-нибудь ДатаГрид из KendoUI? Мне это не надо...
А какой профит тебе от SOAP на других платформах? Да и это проблемы платформы, есть ли там IQueryable или нету. А профит от одаты на js самый прямой, честный REST и только. Да и я тебе уже говорил про js, твоя архитектура - это худшее, что можно взять от MVC. На помойку.Ещё раз, профит SOAP - это количество поддерживаемых платформ + наличие схемы.
МСУАлексей КПолучется:
1. В кроссплатформенных интеграциях ОДата не нужен.
2. Для внутренних взаимодействий нужность ОДата тоже под сомнением.

Офигенная технология!
Вот и получаем:
1. В кроссплатформенных интеграциях ОДата будет использоваться как обычный REST трансфер. Зато для .NET решений открывается лес возможностей.
2. Для внутренних приложений - то, что доктор прописал.1. Для интеграции нет схемы.
2. Внутренние клиенты написаны на JS. Пользы тоже ноль.
...
Рейтинг: 0 / 0
29.10.2014, 17:45
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791073
Фотография EDUARD SAPOTSKI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EDUARD SAPOTSKI
Участник
skyANAСмешно. Покажи мне реализацию настраиваемого фильтра, а?
Ты снова тупишь или прикидываешься?
Так пойдет?
Код: sql
1.
2.
3.
4.
5.
6.
7.
create procedure GetProducts
as
begin
	declare @TopProduct int;
	select @TopProduct = Value from Settings where Name = N'TopProducts';
	select top(@TopProduct) ID, Name, Price from Products;  
end


Как дернуть из шарпа рассказать?
...
Рейтинг: 0 / 0
29.10.2014, 17:48
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791078
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
МСУАлексей КОфигенно! Чтобы потом звонили: "Посмотрите наши JSON пакеты, не понятно, почему ваш сервер их не принимает". Было уже, проходили. В случае с SOAP все неудачники отсылаются к стандарту. В итоге коллеги открывают для себя кодогенерацию и всё налаживается.
Так весь мир работает, есть сервис, есть дока, есть сообщение об ошибке. В 99.9% случаев этого достаточно. Не нужно кривые административные проблемы и неумение поддерживать решения перекладывать на OData. Она тут непричем.В случае с SOAP, если вызов не дошёл до моего прикладного кода в сервисе - можно смело списывать проблему на нарушение формата данных и отправлять коллегу в документацию по стандарту.
МСУАлексей КВидимо, на какой-то другой планете и в другое время.
А может ты сам с другой планеты? Вопрос однако :)Ну я из заМКАДа, да. У нас тут свои законы. :-)
МСУАлексей Кпропущено...
Говорю же - помогает.
Чем? Искуственный интеллект в SOAP?Наличием схемы.
МСУАлексей КООП-модель происходящего в обоих случаях одинаковая. Есть классы сервисов, содержащие логику, и есть DTO, содержащие данные. Сервисы и DTO могут наследоваться. DTO могут инкапсулироваться. Сервисы могут иметь полиморфизм. ОДата всего лишь добавляет стандартные интерфейсы для сервисов, не более того.
Да нахрен мне твои DTO не нужны, я отдаю в OData сразу готовые классы по edmx модели. И они же генерятся на клиенте. За пару кликов - чистое приложение.Ну переходи на Access, там за один клик готовое приложение. :-)
...
Рейтинг: 0 / 0
29.10.2014, 17:51
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791085
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
МСУСмотри, вот базовый класс контроллеров, поставляющих данные для форм, имеющих сохраняемый фильтр и список:
 
Идеальный код
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
public class IndexApiController<TIndex, TFilter> : ApiController
    {
        public IUserDataStore UserData { get; set; }

        public IIndexRepository<TIndex, TFilter> IndexRepository { get; set; }

        #region Actions

        public virtual TFilter GetFilter()
        {
            TFilter result;

            if (UserData.TryGetCompositeValue(FilterKey, out result))
                return ValidateFilter(result) ? result : GetDefaultFilter();

            return GetDefaultFilter();
        }

        [HttpPost]
        public virtual TIndex GetIndexByFilter(TFilter filter)
        {
            UserData.SetCompositeValue(FilterKey, filter);
            return IndexRepository.GetIndexByFilter(filter);
        }

        #endregion

        #region Filter Management

        protected virtual bool ValidateFilter(TFilter filter)
        {
            return true;
        }

        protected virtual TFilter GetDefaultFilter()
        {
            return Activator.CreateInstance<TFilter>();
        }

        protected virtual UserDataKey FilterKey
        {
            get { return new UserDataKey(string.Format("{0}-Filter", GetType().Name)); }
        }

        #endregion
    }

Накой мне тут ОДата?
...
Рейтинг: 0 / 0
29.10.2014, 17:59
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791106
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Алексей КСмотри, вот базовый класс контроллеров, поставляющих данные для форм, имеющих сохраняемый фильтр и список:

Хм. Ну вот я про это и говорил. Вот ещё один пример велосипеда для работы с фильтрами.

Как-то из одного, доставшегося мне "по наследству" проекта ел-еле выпилил подобную (очень похожую на приведённый код) бодягу с фильтрами, сортировкой и пейджингом. Дышать стало намного легче, не нужны теперь никакие нафиг "базовые" контроллеры, а параметры фильтрации/пейджинга/сортировки хранятся, управляются и живут полностью независимой своей жизнью. Надо, повесил. Не надо, убрал. Зашибись. Даже не золотое, а платиновое правило: предпочти аггрегацию наследованию . В рамочку из алмазов на стену каждому разработчику.
...
Рейтинг: 0 / 0
29.10.2014, 18:17
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791121
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Алексей КskyANAпропущено...
Гы... А как ты SOAP Envelope в JS собираешь? Я не хожу в SOAP из JS. Там речь шла про REST + OData.
skyANA Olingo OData Client for JavaScript
Breeze.js

OData Libraries Да зачем это всё надо? Для локальных web-потребностей мне WebAPI + JSON хватает.Ну вот опять мы пришли к тому, что ты оцениваешь технологию сугубо со своей колокольни. При чём тут тогда какие-то кроссплатформенные интеграции?

На JS можно писать кросплатформенные мобильные клиенты, а используя OData Client for JavaScript вполне себе кросплатформенно интегрировать их с сервером :)
...
Рейтинг: 0 / 0
29.10.2014, 18:36
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791126
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Алексей КЕщё раз, профит SOAP - это количество поддерживаемых платформ + наличие схемы.По ссылке выше перечисленны сл. платформы, где реализована поддержка OData: .NET, Java, JavaScript, C++, Other Platforms, - тебе мало? :)
...
Рейтинг: 0 / 0
29.10.2014, 18:39
| Ответить | Цитировать | Написать  
Asp.Net vs WCF
    #38791127
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Алексей К1. Для интеграции нет схемы.В случае с REST + OData зачем какая-то схема?

Алексей К2. Внутренние клиенты написаны на JS. Пользы тоже ноль.Ты хотел сказать НЕ на JS?
...
Рейтинг: 0 / 0
29.10.2014, 18:41
| Ответить | Цитировать | Написать  
25 сообщений из 380, страница 8 из 16
  8  все
Форумы / ASP.NET [игнор отключен] [закрыт для гостей] / Asp.Net vs WCF
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=18&msg=38791059&tid=1354875]:
 0ms
get settings:
 12ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 156ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 64ms
get tp. blocked users:
 1ms
others: 15ms
total:  285ms
созд. / загр.: 285ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]