Достаточно тихо прошло нововведение
интерфейса IMarketDataProvider. Тем не менее, сама фича очень важна, так как она меняет использование самого старого класса -
Security.
Как известно, класс
Security, олицетворяющий собой финансовый инструмент, имеет просто огромное количество полей (классические OHLC, лучшие котировки, последную сделки, греки опционов и многое другое). Пользоваться этим получается достаточно удобно:
Code
// получение цены последней сделки
var lastTradePrice = sber.LastTrade == null ? (decimal?)null : sber.LastTrade.Price;
// получение открытого интереса по РИ
var oi = ri.OpenIntereset;
И чудесным образом подключение к торговой системе через XXXConnector обновляет эти данные. Но в этой красоте скрывается один серьезный недостаток. А что если у нас 2, или даже, 3, поключения (причем, некоторые из них могут быть вполне виртуальными, как
HistoryEmulationConnector)? И все они транслируют данные по многим одинаковым инструментам. Какое подключение будет обновлять данные?
Ответ простой - все одновременно. И мы получаем кашу, если мы используем единые объекты для разных подключений. По-умолчанию, подключения создают отдельные объекты
Security. Тогда перезапись данных невозможно. Но получается другая проблема - разные объекты для одного и того же инструмента.
В итоге родилась идея, чтобы хранить изменяющиеся поля в подключении (точнее, реализации IMarketDataProvider), а константные (код, дата экспирации, шаг цены и т.д.) оставить в классе
Security.
Спешу сразу успокоить - по-умолчанию все работает в классическом режиме. При обновлении вам не нужно "доводить напильником" старый и проверенный код. Но чтобы получить возможность использовать один объект в разных подключения - просто включите
соответствующие режимы. Вот как будет выкглядеть старые код на новый лад:
Code
// получение цены последней сделки
var lastTradePrice = myStrategy.GetSecurityValue<decimal?>(sber, Level1Fields.LastTradePrice);
// получение открытого интереса по РИ
var oi = myStrategy.GetSecurityValue<decimal?>(ri, Level1Fields.OpenIntereset);
Конечно же, это несколько сложнее, чем предыдущий код. Но тем самым будет упрощено взаимодействие с параллельным тестированием и работой стратегий. И да, в
Студии нужно использовать, конечно же, последний вариант. Есть повод для осмысления и модернизации.