Писал развернутый ответ - и тырнет крякнул.
Суть в том что все эти танцы с бубном лишь для того, чтобы сварганить
инструмент, в ктором трейдер будет робота РИСОВАТЬ, а рисовать он
может только в виде детерминированых блок-схем. трейдеру будет трудно
рассказать, как пользовать события, почему вмсето того, чтобы на
снятие заявки получить ответ - успешно или неспешн опрошло снятие, он
должен слушать событие, да и мне - разработчику намного удобнее было
бы написать
if(trader.CancelOrder(order))
{
действия при успешном снятии
else
{
при неуспешном
чем отменять заявку, а потом в событии получть заявку, выснять что
именно это за заявка, и какие действия были с ней в прошлом, и что
делать в будущем..
так же намного удобнее проверять заявку
if( status.Done && PartiallyMatched)
чем слушать событие.
а если заявок много, кторые надо проверять? тут уже в событийно
модели начинаются неудобства :)
Вообще конечно, как мне кажется, много пользы прнес бы смешаный режим,
т.к. выстаявлять заявки удобно в асинхронном - и там уже слушать
событии, а вот снимать например лучше в синхроноом - там сразу ясно -
снял или не снял.А так придется блокировки ставить пояле запроса на
снятии, в событии снимать - ну вы сами понимаетет прелести
ассинхронного программирования. :) Извините что так сумбурно :)
P.S. События жутко удобная вещь для написания всяческого рода
индикаторов, тут они выше всяких похвал.