Здравствуйте, IT, Вы писали:
H_D>>Утверждение 1. Отадвать бизнес логику на клиент — неверно, так как всегда можно залезть "внутрь" объекта и что-то поправить/нарушить/подсмотреть.
IT>Что значит залезть внутрь? Речь о хаках или о преднамеренном обходе программистом ограничений модели?
Речь идет о потенциальной ненадежности выполнения кода на клиенте. Причем необязательно это чей то умысел. Может просто взглюкнуть комп.
H_D>>Утверждение 2. Из (1) следует, что вся бизнес логика живет на сервере и никакая ее часть не может жить на клиенте.
IT>Первичная валидация данных, например. Зачем гонять на сервер строчку "bla-bla-bla", если известно, что она должна содержать маску ###-###-####?
Но при этом проверку
обязательно нужно повторить на сервере.
IT>For that reason, the contract and schema used in service-oriented designs tend to have more flexibility than traditional object-oriented interfaces.
Вот говорю же я что ты от российских реалий слишком отдалился. Проблема обновления софта по всему миру в тысячах офисов перед большинством российских компаний пока не стоит. Честно говоря лично меня мало волнует необходимости работы разнообразнейших версий софта с одним сервером, достаточно обеспечить гарантию работы только нужной версии и легкость обновления до этой версии. Проверить и скачать при необходимости версии интерфейсных сборок не сложно.
IT>Don Box
Это тот самый, который хочет коммуникацию между доменами через soap делать?
IT>Это лишь одно из мест где Дон Бокс пока осторожно упоминает, что на ООП мир клином не сошёлся.
Нифига себе осторожно! Если читать не тех. документацию, а маркетинговые реляции так МС уже вовсю провозгласил отказ от ООП. Тока провозглашать можно еще долго, но пока .NET еще не стал просто средством написания веб сервисов.
По словам моего начальника, когда он у вышеупомянутого товарища попытался узнать, а как же все таки быть с транзакциями, он получил ответ что мол вот есть же в индиге ремоутинг, им и пользуйтесь.
Вобщем опять сплошное определение погоды по почтовому индексу. Может в штатах это и актуально, а вот в России пока нет, и подобные технологии вряд ли станут особо востребованными.
IT> Тем не менее основаная мысль вполне ясна — share schema and contracts, not class. Под это в основном и заточен Indigo.
Поправочка — Indigo Application Services, но не Indigo Remote Objects.
IT>Так что 
IT>Кто там год назад с упорством защищал C++? Пришла пора встать на защиту ООП! Вперёд! 
Это H_D то С++ защищал? Текс, H_D, признавайся, это под каким же ты ником мог позволить себе подобные безобразия?
IT>Хана твоему ООП. Сегодня рулят схемы и контракты 
Пока что только на бумаге.
IT>Это обсуждение мы давай лучше отложим. Я лишь намекну, что на stateless сделать можно всё, т.к. название эта модель получила не из-за того, что состояния в ней нет, а из-за того, что серверные объекты бизнес логики ака сервисы в терминах Дон Бокса, манипулируя этими состояниями, в себе самих их не хранят.
Не, IT, ты уже начинаешь собственное толкование термина сочинять. Стейтлес озночает ничто иное как отсутствие состояния. Если оно наличествует значит это уже не стейтлес.
IT>Состояние же никуда не девается, и следовательно никаких особенных недостатков по сравнению со stateful нет. Есть только преимущества
Опять ты в крайности ударяешься
... << RSDN@Home 1.1.2 beta 2 >>
