Pull to refresh

Comments 8

“type” в Type и т.д. Так же атрибут JsonProperty необходим для сериализации / десериализации свойств, имеющих модификаторы private или static — по умолчанию такие свойства игнорируются.

Если поле в C# называется Type, а в Json type, то он и так приведет
Ну и я бы не называл эти данные динамическими, все же у них есть точные названия и типы полей, на которые вы опираетесь. Работать с действительно динамическими данными — головная боль та еще
За подсказку спасибо liar.

… а за невнимательность — не спасибо ни разу.

в классе JsonConvert есть статический метод DeserializeObject<>

… который всего лишь обертка вокруг JsonSerializer.Deserialize, который и лучше использовать, если вы делаете много десерилизации.


Чтобы связать элемент структуры JSON и свойство класса с произвольным именем, необходимо перед свойством добавить атрибут JsonProperty

… а чтобы не расставлять лишние атрибуты для JSON в "нормальной" конвенции, можно подключить CamelCasePropertyNamesContractResolver.


Так же атрибут JsonProperty необходим для сериализации / десериализации свойств, имеющих модификаторы private или static — по умолчанию такие свойства игнорируются.

Не надо десериализовать ничего в static-свойства.


Поэтому имеет смысл адаптировать класс Order, чтобы в него можно было преобразовывать не только данные команды trade, но также и данные команды user_open_orders.

А зачем? Хорошо видно, что это решение потом ведет к костылям.

А зачем? Хорошо видно, что это решение потом ведет к костылям.

Чтобы не создавать под каждую команду свой класс, например. И вообще, удобно же когда данные оформлены в едином стиле.
Чтобы не создавать под каждую команду свой класс, например.

А зачем тогда вообще пользоваться типизованными DTO? Возьмите dynamic.


И вообще, удобно же когда данные оформлены в едином стиле.

"Единый стиль" не подразумевает использования одного и того же класса для семантически разных объектов. Сделка и открытый ордер — разные сущности.


Удобно, когда разным данным соответствуют разные типы, чтобы нельзя было одно вместо другого случайно использовать.

Да я согласен — это далеко не лучший пример с точки зрения здравого смысла. Я долго сомневался стоит ли вообще этот раздел размещать. Видимо, не нужно было…

Алсо.


_epoch.AddSeconds(Convert.ToDouble(reader.Value)).ToLocalTime()

DateTimeOffset.FromUnixTimeSeconds


List<Order> Last10minuts = new List<Order>();
foreach (var pair in PairList)
foreach (var order in pair.Value)
if (order.Date > DateTime.Now.AddMinutes(-10))
Last10minuts.Add(order);


PairList
.SelectMany(pair => pair.Value)
.Where(order => order.Date > DateTime.Now.AddMinutes(-10))
Ещё хорошо бы DateTime.Now вынести за пределы запроса, и использовать одно и то же значения для всех сравнений, а не запрашивать у системы новое время каждый раз.
Sign up to leave a comment.

Articles

Change theme settings