WLProvider
Алексей Неботов
(статические)", потестить хорошо пока не удалось. К тому же понятно,
что в ходе реализации остальных модулей (и главное модуля Ядро, он
будет менятся.
Его исходники доступны для загрузки http://open-wealth-project.googlecode.com/files/openwealth.zip
Сейчас, в нем, вместо обращения к модулю "Данные" идет обращение к
классу Zaglushka.
Алексей Неботов
файл по линку заменил новым, в который добавил тот самый стрим
провайдер.
меня смущает метод Hearbeat(DateTime) не понимаю зачем он нужен.
и не знаю, где в интерфейсе WL посмотреть свойства Ask и Bid класса
Quote.
Mikhail Sukhov
сынтегрируем его с Квиком (а-ля Церих решение)? В этой части я готов
принять участие как разработчик. Остальной функционал OWP для меня
пока что черный ящик.
Алексей Неботов
> сынтегрируем его с Квиком (а-ля Церих решение)? В этой части я готов
> принять участие как разработчик. Остальной функционал OWP для меня
> пока что черный ящик.
сейчас, немного опережая сбор требований, я думаю над модулем
"Данные". именно в этот модуль интеграция с Quik будет писать данные,
a модуль WLProvider забирать данные.
Не хочу быть привязанным к WL и копировать их классы, да и не
получится это, т.к. нет в WL номера сделки.
Сейчас получается так:
Если есть вопросы/предложения высказывайтесь
using System;
using System.Collections.Generic;
using System.Text;
namespace OpenWealth.Data
{
public class Data
{
/// <summary>
/// Получить данные по заданному символу и scale
/// </summary>
/// <param name="symbol">символ, по которому требуются данные</
param>
/// <param name="scale">требуемый масштаб данных</param>
public Bars GetData(string symbol, Scale scale);
}
public class Bars
{
public string symbol;
public Scale scale;
/// <summary>
/// Добавление данных о тике или баре в базу
/// </summary>
/// <param name="systemKey">Ключ системы, из которой поступают
данные</param>
public void Add(string systemKey, Bar bar);
public Bar GetFirstBar();
public Bar GetLastBar();
public Bar GetNextBar(Bar bar);
public Bar GetNextBar(Bar bar, int step = 1);
public Bar GetPrevBar(Bar bar);
public Bar GetPrevBar(Bar bar, int step = -1);
public Bar Get(DateTime dt);
}
public class Bar
{
public string symbol;
public Scale scale;
/// <param name="number">Номер (если уже есть такие symbol/
scale/number) то существующий бар затерается</param>
/// <param name="dt">время начала бара (должно быть выравнено
по scale) Если scale временной, и данное время scale уже есть в базе,
то существующий бар затерается </param>
/// <param name="open">Цена открытия бара (для тика =close)</
param>
/// <param name="high">Максимальная цена бара (для тика
=close)</param>
/// <param name="low">Минимальная цена бара (для тика =close)</
param>
/// <param name="close">Цена закрытия бара (для тика цена)</
param>
/// <param name="volume">Объем бара</param>
public DateTime dt;
public Int64 number;
public DateTime dt;
public float open; // Float или Double? в Wealth Lab
используют Double и мне нравится как они используют класс DataSeries.
public float high; // но он явно избыточен для данных о цене
public float low;
public float close;
public int volume;
// дополнительная инфа (список, а возможно и типы, которой на
этапе компиляции не определены) !!!!! как её хронить?
// например направление сделки / стакан и т.п.
}
}
Mikhail Sukhov
паттерн свечка, причем с разными нарезками.
2. Как стильно C# - плохо. Почитай naming convention.
3. На каком FW пишешь? Если выбрал самый последний, учти - работать не
будет с прогами, написанных на 2.0, 3.0, 3.5
4. Если против S#, то начинай использовать нормальные бизнес сущности,
а не велсовскую дребедень ввиде string symbol.
Леш, так что насчет стрима? Откуда он у тебя данные качает?
Алексей Неботов
> паттерн свечка, причем с разными нарезками.
об абстрактном классе Candle проекта S#
http://stocksharp.com/doc/help/html/AllMembers_T_Ecng_Trading_BusinessEntities_Candle.htm
не понимаю зачем в базовом классе нужно:
CloseVolume
HighVolume
LowVolume
OpenVolume
TotalPrice
?
о IExtendableEntity.ExtensionInfo:
примерно также планирую сделать хранение дополнительных параметров.
Только думаю, может вместо object в качестве ключа сделать string.
> 2. Как стильно C# - плохо. Почитай naming convention.
что конкретно? Или я не понял комментария.
> 3. На каком FW пишешь? Если выбрал самый последний, учти - работать не
> будет с прогами, написанных на 2.0, 3.0, 3.5
пишу в 2.0, но иногда компилирую в более высоких.
> 4. Если против S#, то начинай использовать нормальные бизнес сущности,
> а не велсовскую дребедень ввиде string symbol.
я не против S#, я против зависимостей, которые усложнят, а не упростят
архитектуру.
хотя отдельные модули могут иметь зависимости, в этом нет нечего
плохого,
но к зависимостям ядра я отношусь очень осторожно. Даже о log4net
думаю, как бы без него.
просто в итоге можно попасть в ситуацию, когда поменять хочется, но
сделать это не перелопачивая всё сложно.
string symbol имеет как плюсы, так конечно и минусы. Минусов пожалуй
больше.
Вообще, я предполагаю, что в разных системах один и тот же символ
может иметь разные названия. И в этом случае string явно не катит.
> Леш, так что насчет стрима? Откуда он у тебя данные качает?
в данный момент из random. А вообще из модуля Данные по событию в
классе Bars.
Сейчас алгоритм работы с данными вижу так:
1) У некоего, общего менеджера:
1.1) модуль, получающий данные запрашивается Bars для определенного
Инструмента/Фрейма. Получает объект.
1.2) модуль, публикующий данные запрашивается Bars для
определенного Инструмента/Фрейма. Получает ТОТ ЖЕ САМЫЙ ОБЪЕКТ.
Самое страшное, что входящие данные могут быть в одном (не обязательно
тиковом) таймфрейме, а потребитель может хотеть другой (больший)
таймфрейм. И схему привидения таймфрейма к требуемому я пока не
придумал.
Например: на входе есть минутки, и пяти минутки. Потребитель запросил
часовики.
Mikhail Sukhov
> CloseVolume
В своей структуре ты указал цену закрытия. В S# добавлен еще объем
закрытия. Из этих побуждений.
> > 2. Как стильно C# - плохо. Почитай naming convention.
>
> что конкретно? Или я не понял комментария.
Стольно = стиль. Основное здесь - http://msdn.microsoft.com/en-us/library/ms229045.aspx
Ну и по гуглу C# naming convention. У тебя стиль не .NET-ий (и не C#).
> я не против S#, я против зависимостей, которые усложнят, а не упростят
> архитектуру.
> хотя отдельные модули могут иметь зависимости, в этом нет нечего
> плохого,
> но к зависимостям ядра я отношусь очень осторожно. Даже о log4net
> думаю, как бы без него.
Честно? Я не думаю, что трейдеры будут заниматься
модулесобирательством. С тех стороны тоже сомнительная выгода (если
уже сейчас на этапе проектированию идут ограничения, то что будет
потом). Но разводить полемику ввиде, кто круче, кит или слон, как в
соседнем топике не буду. мне пока только часть OWP интересна.
On 13 сен, 16:52, Алексей Неботов <anebo...@gmail.com> wrote:
> > 1. Что не хочешь использовать бизнес сущности из S#? Там уже есть
> > паттерн свечка, причем с разными нарезками.
>
> об абстрактном классе Candle проекта S#http://stocksharp.com/doc/help/html/AllMembers_T_Ecng_Trading_Busines...