Михаил, я начал писать реализацию iTrader для S#, точнее пока только написал вроппер вокруг их библиотеки. И возникли некоторые вопросы по поводу дизайна базовых типов, а именно: почему Candle абстрактный, почему в itrader передаются не интерфейсы, а классы( например Candle а можно было сделать просто ICandle?). Вопросы эти возникли по следующей причине: Transaq Connector сделан по-дурацки он обменивается с программой неполноценными xml(зачем они эту ересь сделали не представляю-руки бы поотрывал тому кто это придумал). Поэтому я написал свои типы которые сериализуются и десериализуются. Встал вопрос совместимости с вашими типами. Унаследовать от Ваших классов не могу( мне же нужно сериализовать или десериализовать-а делаю это с помощью атрибутов). Были бы интерфейсы-никаких проблем. Эту проблему я конечно обойду-напишу преобразование типов. Но хочется чтобы пользователь имел доступ к дополнительным данным( ведь коннектор впринципе по некоторым полям передает больше значений). Итого: предлагаю Вам рассмотреть возможность использования только интерфейсов в iTrader. Тогда конкретная реализация зависела бы коннектора и могла учитывать какие-то его особенности или нести доп. поля.
コメント (8)
ログイン または アカウントを作成, コメントを残すにはログインまたは新規登録してください
Потому что это базовый класс. Обычно под счетчками подрузомевают временные. Для них как раз есть проивзодный от Candle класс - TimeFrameCandle.
Там где нет реализации - использую интерфейсы. Там где есть - использую классы.
Товарщини изобрели веб сервис😀
Ручками или какой-то спец механизм, аля XmlSerializer?
Расскажите по подробнее о механизме сериализации и как это работает в транзаке. Попробую предложить решение.
Доп поля записываются через ExtensionInfo
Нет, боже упаси это делать ручками. Да через сериалайзер. Только сейчас пришла идея делать через xslt-тогда можно все привести к базовому классу. но уже поздно-код написан, да медленная это вещь. и не говорите- изобрели блин да не тем местом, колеса вдруг стали квадратными. один способо как с этим побороться я знаю-создать новый класс, производный от Вашего и написать в моем классе метод преобразования к этому классу, мне он не нравится тем что мне еще придется плодить классы, может у Вас есть предложение как это реализовать без создания еще новых классов? Тут основная проблема в том, что я не смогу переопределить сериализацию у Ваших типов( ну или это будет весьма геморно), точнее у их полей.
Интересно, а что, там названия у нод и атрибутов любые могут быть? Или Вы поля у сущности назвали так же, как принято у Транзака? Если второе, то это не очень хорошо. Я раньше так же начинал с Квиком, делать десериализацию ДДЕ данных сразу в сущности. Потом такие траблы начались ввиде больших переделок на добавление нового поля.
Так что для себя я решил. Создание нового трейдера начинается с тотальной обертки АПИ. И эта обертка никак не использует типы S#. А сам трейдер лишь делает конвертацию данных туда и обратно.
Согласен. Я использую свою сериализацию на основе Ecng.Serialization. Отличается от стандартной тем, что можно контролировать процесс сериализации.
На метаданных (атрибуты или xml). Отличается наличием конвертеров. Например, сложные типы (картинки, шифрованные строчки, сетевые адреса) в xml так просто не запихать. Приходится создавать структуру только для сериализации, где такие типы упакованы в примитивный формат (строка, число). Ecng.Serialization использует конвертеры на поля. Он превращает сложный тип в простой при сериализации и наоборот.
И еще одно большое отличие - SerializatonItem. Это древовидная структура, которая содержит данные для записи в файл (или только то прочитанные из). Плюс в том, что эти данные можно потом передавать куда угодно. И записывать как угодно. Со стандартными сериализаторами такое не прокатит.
Пришлите мне какой-нить юз кейс из транзака и как Вы хотите его использовать с типом S#, а я вставлю код для работы через Ecng.Serialization.
Пока времени не было чтобы начать реализовать iTrader. Это пример прямо из кода использования стандартной десериализации для callback. для отправки команд я сериализую ручками( для десериализации бы это потребовало очень много времени). Вот пример xml ки которую должна парсить эта функция:
Напишите, пожалуйста, пример того как это будет выглядеть при Вашей десериализации.
Стандартная сериализация позволяет контролировать только весь процесс в целом, а не какое-то отдельное поле. Да и реализовать интерфейс IXmlSerializable мягко говоря не для слабонервных.
Спасибо, Михаил.