Здравствуйте, IT, Вы писали:
IT>А причём тут интероп, я говорю что наверняка было бы легче всё написать на чистом нете с нуля.
Я очень ленивый человек. Если было бы проще, написал бы на Шарпе. Первая попытка была именно на нем. Но писать все с абсолютного нуля — это слишком, а писать а WinAPI-шного нуля на Шарпе дико не удобно. Ошибок в разы больше чем на плюсах, да еще каждую функцию и константу нужно вручную описывать... В общем по сравнению с проблемами вызываемыми Шарпом пробшемы МС++ в данном случае просто смехотворны. К тому же я давно автоматизировал копирование, а замена версии на статически заданную решила проблемы несовместимости.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
VD>>Я очень ленивый человек. Если было бы проще, написал бы на Шарпе.
IT>Не понял, ты чё гридов никогда не писал? Зачем тебе апишные функции? Всё что тебе надо — кисточка и карандаш
Вот потому что писал (см. ascDB), потому так и не делаю. Это трах на пол кода с отрывом от производства. Хотя может и стоило бы. А то грид из .нэт тормозной и кривой.
Кстати, в МС тоже много линивых. Их только на кривенький гид хватило. Все остальное обертки над апи, только хреновые и на Шарппе.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
MS>Но в ремотинге есть такое понятие как event-ы, чего нет в Web Service-ах (нормальным путем не добится). MS>Если ты отделил Win32 клиентов от Remoting с помощью Web Service то как ты решил эту проблему? Или же у тебя как то по другому?
И слава бугу что нет! Ты еще мало носом тыкался в нешениях основанных на колбэках. В сети (особенно в Интернет) — это самое худшее решение. Ты сразу снижаешь надежность всей системы до надежности самой ненадежной части сети. Стоит одному клиенту подвеснуть или выдернуть шнур из компьютера и ты приплыл.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Сервер он хоть с калбеками, хоть без калбеков сервер. Калбеки, решая определённый круг задач, значительно усложняют всю структуру приложения. А как известно, усложнять просто, упрощать сложно.
Они еще надежность снижают. И нехило.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, MikaRSDN Soukhov, Вы писали:
MS>Клиент отвалится Эвент выкинули и когда снова подключился то получили новый MS>Что пропало то?
Это означает, что все вызовы ты делаешь в отдельных потоках обеспечивая функциональность сравнимую с MOM (типа MSMQ). А это тоже дурь, так как объем работы большой, а толку от него почти нет (MOM уже существуют давно, и реализованв они явно лучше).
MS>Да Тут единственно место где single call лучше Но только здесь (и до поры до времени)
Ты не прав. У вас просто пока маленькие объемы колбэков и давольно надежная сеть. Если эти услвия изменятся, ты поймешь почему ты не прав.
MS>Тоже и у нас Просто на эвентах много было всего посторено и чтобы не ломать логику решили таким путем Хорошим путем
А здесь нужно было с самого начала проектировать грамотно. Если логика рассчитана на сервер, то никаких колбэков или используйте MOM. Это закон проектирования надежных многопользовательских систем.
MS>Да чем раздражают то !? Все нормально Может ты и изменения файла будешь отсматривать путем сканирования его 50 раз в сек ?
А ты вот к примеру на Хоум глять. Там как раз изменения отслеживаются и без единого колбэка.
IT>>Периодический опрос сервера клиентом MS>Докажешь что лучше, сделаем так.
Сам когда нибудь поймешь почему.
MS>Про когда я проигнорирую с ответом Ну а насчет сервера По-моему я уже сказал Сервер это активная субстанция которая сама может реагировать на действия и их возбуждать А у тебя это простой вызов функции из DLL
Может, но с клиентами по своему усмотрению общаться не имеет права. Только с серверами связанными надежными каналами. В общем единственным разумным выходом в твоей ситуации является использование МОМ. А их можно и на веб сервисах писать.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Нет. В отличие от евентов, MSMQ гарантирует доставку. IT прав.
Более того MSMQ позволяет легко организовать асинхронную доставку сообщений.
S>Вообще архитектура, существенно использующая колбэки как часть логики, обречена. Почему? А потому, что у тебя получается двусторонняя зависимость между сервером и клиентом. Т.е. tight coupling, единогласно проклинаемый всеми гуру от архитектуры. Надежность системы начинает резко зависеть от надежности связи между клиентом и сервером.
И от самого клиента! Т.е. клиентом (причем каждый) становится частью сервера.
В общем я бы сформулировал так. События допустимы в надежных клиент-срверных системах только при соблюдениях следующих правил:
1. Сервер не имеет зависимости от клиента (ни временной ни локической)
2. Клиент умеет объходиться без данных передаваемых через события.
Качественно такие условия можно выполнить только используя MOM типа того же MSMQ.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, MikaRSDN Soukhov, Вы писали:
MS>Здравствуйте, Sinclair, Вы писали:
MS>Можешь рассказать чем хорош MSMQ (можно и линки на статьи) MS> А пока один конкретный вопрос. Мы располагаем очереди сообщений на клиентской части или серверной (если на последней то как тогда получить эвент о том что пришло сообщение от сервера)?
Здравствуйте, MikaRSDN Soukhov, Вы писали:
MS>Тогда следует такой вопрос а в Web Service можно использовать MSMQ
Нет конечно. MSMQ — это почти протокол. Работает поверх TCP так что в Интернете его приенять можно, но по HTTP он не работает.
MS>Если нет то COM+ лучше в этом случае
В COM+ есть кьюед-компоненты. Они реализованы на MSMQ. Причем они значительно медленнее чем прямая работа с MSMQ. Да и работать с ними не проще. COM+ же без кьюед-компонентов используемый для колбэков — это неверное решение. Почему? Да тебе сдесь уде многи об этом рассказывали.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Серверные эвенты это вобще относительно новое веяние.
Ошибаешся. Просто на обычном RPC они не надежны быи, и потому не прижились. За то есть MOM. Там все на эвентах. Там даже вызов сервера (прямой) — это в чистом виде эвент.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, MikaRSDN Soukhov, Вы писали:
MS> Ты же хочешь чтобы вся логика хранилась на серваке ну и как с хранимыми процедурами А вот если есть такой человек который захочет что то изменить в процедуре ентой Он изменяет на сервера Так? А что если он хочет изменить локигу не серверную а клиентскую Опять на сервер? А кто ему доступ даст? Ведь сервер-админ >>> клиент-админ
В классическом клиент-сервере еслть понятие логики данных, прикладной логики и презентационной логики. Призентационная — это и есть клиентская. Но в отличии от твоего представления — не логика приложения. Это всголишь код занимающийся локальной обработкой информации для идинственного клиента. Локальной — значит, что эта логика никак не влияет на сервер. Если приложение влияет на сервер, оно само становится сервером и о клиент-серевер речь еже не идет. В этом случае у тебя получается большое распределенное приложение. И сделать надежным такое приложение очень и очень сложно. Решения есть только два (ну можне быть пока ):
1. Использование для связи МОМ и виделение главных серверо. При этом второстепенные серверы используют обратную связь только в асинхронном режиме. Надежность передачи обеспечивается МОМ-ом.
2. Помещение приложения в кластре. Для клиентов неприемлемо.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, MikaRSDN Soukhov, Вы писали:
MS>Будут, будут Это точно Но вот вопрос времени, когда?
Когда МОМ заточат под вэб. Возможно уже ходят.
MS>Подожди Тут я не утверждаю что у нас система была завязана на эвентах потому и не ломал ее Я не ломал потому, что это было правильным решением А спрашивать сервер до опупения, не случилось ли что нить,- это ИМХО не правильно.
Так не обязательно до отупения. Мделай кнопку рефешь. Ну или используй для событий МОМ.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Eugene Hrulev, Вы писали:
EH>А такой вариант реализации ивентов: — посылка (синхронного) запроса на сервер (из отдельного клиентского потока). Ответ сервера — это и будет "посылка" ивента клиенту? (Естественно с отработкой всяких таймаутов)
EH>Сервер при этом остается самым пассивным из пассивных.
Но реализовывать логику в клиенте при этом нельзя. Так как она может и не выполниться. Ну или логика далжна быть презентационной (т.е. на нее должно быть можно наплювать).
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
EH>>А такой вариант реализации ивентов: — посылка (синхронного) запроса на сервер (из отдельного клиентского потока). Ответ сервера — это и будет "посылка" ивента клиенту? (Естественно с отработкой всяких таймаутов) EH>>Сервер при этом остается самым пассивным из пассивных.
VD>Но реализовывать логику в клиенте при этом нельзя. Так как она может и не выполниться. Ну или логика далжна быть презентационной (т.е. на нее должно быть можно наплювать).
Я согласен. Вот только смущают такие моменты.
Презентативная логика. Здесь возможны 2 варианта:
1) — в стиле Web-интерфейса. Поведением всех визуальных компонентов управляет сервер.
На который при этом явно ложится лишняя нагрузка. И, главное, в отличие от Web-интерфейса не стандартизированы визуальные компоненты — т.е. каждый разработчик сам
конструирует передачу событий от кнопок etc. на сервер, прием и отображение свойст визуальных
компонентов.
2) — Поведением всех визуальных компонентов управляет клиент. Который, в свою очередь, кроме
презентативной логики должен знать и о части бизнес-логики, от которой презентативная логика
полностью зависит. Вот это уже более стандартизировано — например ADO.NET с их
"отсоединенными" датасетами.
И в частности, клиент должен уметь хранить массу справочной (т.е. редко меняющейся)
информации, дабы не обращаться постоянно к серверу. А вот тут и возникает вопрос о неких
"событиях" об изменениях, получаемых с сервера. И вопрос, соответственно, именно о том, как
реализовать поставку этих "событий" с сервера на клиента. Просто периодический опрос сервера
насчет изменений:
во-первых, создает лишнюю нагрузку на сеть/сервер,
во-вторых принципиально не отличается от простого "перечитывания" информации с сервера
ну и во-третьих, выглядит как-то неэлегантно
Здравствуйте, mrhru, Вы писали:
M>1) — в стиле Web-интерфейса.
Ну в вебе есть такие вещи как скрипты и програмы на Яве или .Нэт. Вот они могут являться презантационной логикой. Иначе это мертвый хтмл который и логикой то не обладает.
M>2) — Поведением всех визуальных компонентов управляет клиент. Который, в свою очередь, кроме M> презентативной логики должен знать и о части бизнес-логики, от которой презентативная логика M> полностью зависит.
Да знать он может все что угодно и зависить может от чего угодно. Презиетационная логика может быть даже иногда копией серверной. Главное чтобы от нее не зависил сервер.
M> Вот это уже более стандартизировано — например ADO.NET с их M> "отсоединенными" датасетами.
Отсоединенный адасет — это не более чем массив данных. Только динамический и разными наворотим. Сервер отдает его клиенту, и тот должен отобразить данные пользователю (отформатировав их как ему нравится) и позволить пользователю изменить эти данные. Далее она должна взять дельту (изменения) и отослать на сервер. И тут уже начнется вторая часть бизнеслогики. Сервер долен сделать нужные проверки и записать изменения в БД. При этом сервер приложений может выпендриваться как хочешь. Да и клиент волен делать все что угодно. Например он может с дублировать вычисления производимые на сервере чтобы пользователь чувствовал интерактивность. И все это будет правильно и не будет нарушать "правильную" модель. Но вот если клиент начнет делать некую логику которую не в силах отследить сервер. И эта логика начнет влить на данные. Вот здесь то и могут появиться проблемы.
Вот живой (и довольно безобидный) пример с нашего сайта. На RSDN есть бизнеслогика которая говорит, что нельзя постить сообщения которые не имеют названия темы. Серверная логика реализована в некой хранимой процедуре (да не важно где). Но она не проверяет это правило. Зато проверкой занимается или скрипт на клиенте или ASP.NET страничка. Так вот появляется вторая точка в которой можно добавить сообщение (Хоум) в нем проверка не сделана и в базу попадают темы без названия. Это совсем безобидная ошибка. Но она хорошо показывает принцип разделения логики. Вся серьезная логика должна проверяться и отрабатываться на сервере. Так вот с кобэками зачастую бывает именно так что часть логики начинает выполняться на клиенте. Причем эта часть встроена между общей логикой сервера и сервер начинает очень сильно зависит от этого промежуточного звена.
M> И в частности, клиент должен уметь хранить массу справочной (т.е. редко меняющейся) M> информации, дабы не обращаться постоянно к серверу.
Только в виде кэша. Информация должна быть первична на сервере. А клиент должен ее отображать. Он может кэшировать ее, но нужно подразумевать что кэш может измениться в любое время. Можно даже придумать систему автоматической перечитки. Но вот события здесь не лучший вариант. Дело в том что очень не просто создать систему событий которая будет "умно" уведомлять клиента. Обычно все скатывается на то что на каждый апдэйт данных рассылается уведомление каждому клиенту. Такой подход (даже если проблемы с надежностью решены) может привести к проблемам с производительностью. Ну и в любом случае нужно предусмотреть полную ручную перечитку данных, так как уведомление может попросту потеряться.
M> А вот тут и возникает вопрос о неких M> "событиях" об изменениях, получаемых с сервера. И вопрос, соответственно, именно о том, как M> реализовать поставку этих "событий" с сервера на клиента. Просто периодический опрос сервера M> насчет изменений: M> во-первых, создает лишнюю нагрузку на сеть/сервер,
Не факт. Если опрос делается вручную. Или с большим интервалом общая нагрузка может быть намного меньше, чем широковещательные уведомления.
M> во-вторых принципиально не отличается от простого "перечитывания" информации с сервера M> ну и во-третьих, выглядит как-то неэлегантно
Возможно и не элегантно, но зато:
1. Это работает.
2. Легко реализуемо.
В общем если говорить об уведомлениях, то здесь нужно понимать две вещи:
1. События нужно делать так чтобы от них ничего не зависело, т.е. чтобы если произойдет ошибка, то не должны пострадать данные, и нужно иметь возможность легко устранить рассинхронизацию.
2. Нужно очень серьезно продумать тактику уведомлений чтобы минимизировать количество клиентов которых нужно уведомлять. Например если изменился заказ, нужно точно знать какой клиент имеет его открытым и уведомлять только его. Поверь, это очень непростая задача.
3. Уведомления нужно делать на МОМ. Чтобы избежать реализации МОМ своими силами.
В итоге мы получаем следующие выводы: Сделать систему с уведомлениями можно, но сложно. Поэтому принимая решение об взятии на себя такого геморроя нужно сто раз подумать, а нельзя ли обойтись простым перечитыванием?
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
IT>>RSDN внутри никогда не делался как клиент-серверное приложение (не путать с веб-сервером). Слишком дорого.
VD>Ничего там другого нет. Чистый к-с.
Я же говорю — не путать! Внутри он обычное двухуровневое, без всяких лейеров и прочей многоуровневой лабуды.
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
Это трах на пол кода с отрывом от производства. Хотя может и стоило бы. А то грид из .нэт тормозной и кривой. 
