Здравствуйте, Mike Chaliy, Вы писали:
MC> Мне с этим сложно согласиться, так как сущности модели в 98% случаев отличаються от того что хотелось бы передать.
Если сущности на 98% отличаются от того, что хочется передать, значит они на 98% не правильно спроектированы.
MC>Я хочу чтобы контракт менялся только тогда когда это нужно, а не тогда когда поменялась бизнес логика.
Контракт никак не зависит от бизнес-логики, так как в стройной модели никакой бизнес-логики не содержится.
MC>Судя по всему "мега-архитект" не вкурсе что в SOAP нет ни слова про сверхжесткость контракта данных.
Дело не в словах, а в том как это на самом деле работает. В SOAP ты должен явно и жестко прописать контракт и строго ему следовать. Малейшее изменение контракта порождает новую версию сервиса. Именно об этом и говорил Синклер, когда присал про сверхжесткость. Изменение однажды созданного DTO порождает новую версию сервиса, при том, что старые клиенты никуда не деваются и при самом печальном раскладе, необходимо поддерживать все когда-либо созданные версии DTO и сервисов — в этом собственно и есть основная проблема SOAP, которую призван решить REST.
MC>SOAP вообще глубоко ложить на то что вы передадите в боди. Даже вебсервисы асп.нет потдерживают этот режим...
Проблема, что только они этот режим и поддерживают.
MC> По ходу, все тоже самое справедливо и для РЕСТ... И никак оно проблемы сложных ДТО не решает.
Ключевое отличие REST в том, что в нем DTO фактически генерится на лету, во время построения запроса. Неким подобием контракта ограничины только базовые сущности, по которым строится запрос. Именно это и решает "прблемы сложных DTO" и объясняет популярность REST.
По ходу, вы там собирались игонрить эту тему... Забыли?
IB>Здравствуйте, Mike Chaliy, Вы писали:
MC>> Мне с этим сложно согласиться, так как сущности модели в 98% случаев отличаються от того что хотелось бы передать. IB>Если сущности на 98% отличаются от того, что хочется передать, значит они на 98% не правильно спроектированы.
Это из категории "ляпнул и не обосновываеш".
В одном из моих проектов несколько фронтендов к доменной логике. На примере кастомера, для УИ фронтедна у меня у кастомера около 40ка полней, для веб-сервиса около 10ти. Я не вижу необходимости пердавать остальные трдицать тока ради того что "не правильно спроектированы"... Пойми же в рич модели никто не тычит эти обьекты куда попадя и куда не попадя, как в "стройной". В рич моделях всегда еться фасады кторые отдают тока то что надо и не одной пропертей больше.
MC>>Я хочу чтобы контракт менялся только тогда когда это нужно, а не тогда когда поменялась бизнес логика. IB>Контракт никак не зависит от бизнес-логики, так как в стройной модели никакой бизнес-логики не содержится.
MC>>Судя по всему "мега-архитект" не вкурсе что в SOAP нет ни слова про сверхжесткость контракта данных. IB>Дело не в словах, а в том как это на самом деле работает. В SOAP ты должен явно и жестко прописать контракт и строго ему следовать. Малейшее изменение контракта порождает новую версию сервиса. Именно об этом и говорил Синклер, когда присал про сверхжесткость. Изменение однажды созданного DTO порождает новую версию сервиса, при том, что старые клиенты никуда не деваются и при самом печальном раскладе, необходимо поддерживать все когда-либо созданные версии DTO и сервисов — в этом собственно и есть основная проблема SOAP, которую призван решить REST.
1) В SOAP я ниего не должен. В теории контракт можно ограничить WDSL (и XSD). Это теория. SOAP можно использовать и с ad-hoc XML. Более того громадное количество спек на этом свободно основываеться (пример WS-Management).
2) Если у меня не изменяет память то у Синклера всегда было свое виденье на веб-сервисы, которое основываеться на том что может фреймворк который он использует... А мож и не у Синклера... Не суть.
3) Версия добовляеться тока в случае "ломающих" изменений. Добовления парметра, аргумента не требуют добовления новой версии.
4) В REST все тожде самое. Точно также как и в SOAP у него тем или иным способом описывают схему. Пока что в REST нет стандарта на это но все к тому идет. Можеш поискать, это легко находиться. Без схемы в том или ином виде ты не сможеш консьюмить не тот, не тот сервис.
5) Единственное существенное отличие между SOAP и REST это семантика. В SOAP сообщения, в REST изменение состояния. Все. Решения твоей "проблемы" у REST даже в мыслях небыло....
MC>>SOAP вообще глубоко ложить на то что вы передадите в боди. Даже вебсервисы асп.нет потдерживают этот режим... IB>Проблема, что только они этот режим и поддерживают.
гм, они оба режима подтдерживают... в чем проблема?
MC>> По ходу, все тоже самое справедливо и для РЕСТ... И никак оно проблемы сложных ДТО не решает. IB>Ключевое отличие REST в том, что в нем DTO фактически генерится на лету, во время построения запроса. Неким подобием контракта ограничины только базовые сущности, по которым строится запрос. Именно это и решает "прблемы сложных DTO" и объясняет популярность REST.
Ыыыыыы, вы это откуда взяли? Мож стоит почитать про него? Ну хотябы немного? Теорию. Даже википедии достаточно.
Здравствуйте, Mike Chaliy, Вы писали:
MC>Это из категории "ляпнул и не обосновываеш".
Ну так ты тем же самым занимаешься, какой вопрос — такой и ответ.
MC> На примере кастомера, для УИ фронтедна у меня у кастомера около 40ка полней, для веб-сервиса около 10ти.
А внутри ты у себя все 40, во всех сценариях используешь? Ага.
MC> Я не вижу необходимости пердавать остальные трдицать тока ради того что "не правильно спроектированы"...
Ну тут уж сам решай.. =)
MC> В рич моделях всегда еться фасады кторые отдают тока то что надо и не одной пропертей больше.
В стройной модели, тоже ни одной пропертей больше. Только в стройной, кроме этих фасадов ничего больше нет, а в жирной, существуют более фасадистые фасады, отягощенные всякой логикой из за чего для фасадистых фасадов приходится писать дополнительные фасады. Ничего не устанет, фасады к фасадам писать?
MC>1) В SOAP я ниего не должен. В теории контракт можно ограничить WDSL (и XSD). Это теория.
Это практика. В SOAP клиент не может сказать серверу — верни мне кастомеров с 3-го по 8-й, за вчерашний день, если разработчик на сервере не предусмотрел соответствующего метода. Были, конечно попытки это дело обойти, expressin-tree сериализуя, например, но чтобы что-то из этого увенчалось успехом, я не слышал.
MC>2) Если у меня не изменяет память то у Синклера всегда было свое виденье на веб-сервисы, которое основываеться на том что может фреймворк который он использует... А мож и не у Синклера... Не суть.
Сильный аргумент =) Так суть или не суть? Дело в том, что Синклер столкнулся с этим именно на практике, так как у него может быть произвольный фреймворк на противоположной стороне и куча разношерстных клиентов со своими хотелками — как раз тот сценарий, ради которого SOAP и задумывался. Так что я бы на твоем месте его бы послушал, вместо википедии..
MC>3) Версия добовляеться тока в случае "ломающих" изменений. Добовления парметра, аргумента не требуют добовления новой версии.
Хрен редьки не слаще, да и не про добавление параметра речь.
MC>4) В REST все тожде самое. Точно также как и в SOAP у него тем или иным способом описывают схему. MC> Пока что в REST нет стандарта на это но все к тому идет. Можеш поискать, это легко находиться. Без схемы в том или ином виде ты не сможеш консьюмить не тот, не тот сервис.
Не тоже и не ту схему там описывают. В конечном итоге, в REST клиент определяет что именно он получит, а в SOAP это все жестко прошито на сервере.
MC>5) Единственное существенное отличие между SOAP и REST это семантика.
Семантика чего? =)
MC>гм, они оба режима подтдерживают... в чем проблема?
Проблема в том, что далеко не все реализации SOAP так умеют. Сценарий когда на обоих сторонах один и тот же фреймворк — мало интересен, там хоть голые данные гоняй, как-нибудь договорятся.
MC>Ыыыыыы, вы это откуда взяли? Мож стоит почитать про него? Ну хотябы немного? Теорию. Даже википедии достаточно.
Да, стоит — почитай.
Здравствуйте, Sinclair, Вы писали:
S>Речь идет о построении внешней модели под конкретный случай. Да, мы изобретаем специальный DTO "Ордер с айтемами" и отдаем его.
Дело в том, что одним из недостатков жирной модели объявляется невозможность отдавать ее на клиента. Поинт в том, что тонкую модель можно отдавать, но юзкейсы когда нас удовлетворяет возврат сервером MyThinkObject или MyThinkObject[] я встречаю очень редко. Если мы конечно ратуем за минимизацию серверных вызовов и не хотим нарваться на несогласованность данных.
S>При том, что в РЕСТ нет проблемы сверхжесткости контракта, придуманной идиотами-авторами SOAP. Контракт в REST легко расширять обратно совместимым образом.
А можно какие-то ссылки описывающие контракт РЕСТ? Все, что я читал по этом поводу не наводило меня на мысли о какой-то спецификации контракта. У меня сложилось впечатление, что РЕСТ это способ построения архитектуры на контрактах сервера в стиле CRUD (точнее GPPD, но эту аббревиатуру я не встречал). Правда я уже давно не слежу за его развитием, поскольку идеи впечатляют, а реализации не очень, так что буду благодарен за любую инфу. Было бы совсем здорово статью на РСДН (мечтать).
Здравствуйте, Ziaw, Вы писали: Z>А можно какие-то ссылки описывающие контракт РЕСТ?
Ну, вообще описывать контракт в REST не обязательно — он, типа, такой self-descriptive, что контракт как бы и не нужен.
Всё, что нужно знать — это адрес точки входа. Все остальные "места" в REST-пространстве должны быть достижимы по ссылкам из входной точки (connectedness), а их смысл легко будет понятен человеку, который по ним кликает. То есть специальных усилия для обеспечения discoverability не нужно.
Но на практике нам важно два фактора:
1. Анализ документа. В простейших случаях документ используется как монолит: к примеру, это картинка, которую мы показываем пользователю as is.
В остальных случаях нужно из полученного документа что-то извлекать. Как правило, документ — это некий XML. XML позволяет авторам сервиса легко расширять структуру, но вот для сохранения совместимости нужно как-то объяснить потребителям правильный способ доставания данных.
Ну, чтобы парни не имели искушения вытаскивать ссылку на EULA как "четырнацатый link в документе", что сломается при малейшем изменении схемы.
Поэтому контракт на структуру документа можно описать в виде набора XPath-выражений, которые обязуются вернуть определенные данные.
В принципе, этого достаточно. Пользуясь контрактами, потребитель может понять, как ему из корневого документа найти ссылку на региональные документы, как выбрать из них нужный, как получить адрес регионального документа, как из регионального документа вытащить список филиалов, как получить документ со списком прайс-листов на филиалы, как получить данные прайс-листа на заданную дату.
Но заставлять его делать это каждый раз — не всегда эффективно; поэтому иногда автор сервиса еще и публикует схему адресации документов.
И тогда потребитель может сразу запросить /sibir/tomsk/prices/2009/02/21.xhtml. Но тогда автору сервиса придется гарантировать целостность этих ссылок; и если что-то поменяется, придется держать настроенные редиректы в течение длительного срока.
Z>Все, что я читал по этом поводу не наводило меня на мысли о какой-то спецификации контракта. У меня сложилось впечатление, что РЕСТ это способ построения архитектуры на контрактах сервера в стиле CRUD (точнее GPPD, но эту аббревиатуру я не встречал).
Совершенно верно. REST — это способ построения архитектуры. Но у этих архитектур есть типичные черты. Посмотри на http://code.google.com/apis/gdata/ — там приведены контракты на рестовские интерфейсы гугла.
Вот, собственно, основа: http://code.google.com/apis/gdata/docs/2.0/reference.html
Обрати внимание, что приведена спецификация устройства URL, а также спецификация на структуру возвращаемого документа.
Правда я уже давно не слежу за его развитием, поскольку идеи впечатляют, а реализации не очень, так что буду благодарен за любую инфу. Было бы совсем здорово статью на РСДН (мечтать).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Мы уже победили, просто это еще не так заметно...
