.NET

индекс
121,03

DynamicObject, JSON и ближайшее будущее

В данной статье хочу ознакомить вас с небольшим приложением для работы с JSON данными, демонстрирующим возможности, доступные нам в .NET 4.0. Поверхностно будут рассмотрены вопросы JSON-формата, а так же работы с динамическими типами данных.

JSON



Есть такая классная шутка, известная широким массам:

3763158824_e2f57810c4[1] JSON (Javascript Object Notation) — простой формат обмена данными, удобный для чтения и написания как человеком, так и компьютером. Он основан на подмножестве языка программирования Javascript, определенного в стандарте ECMA-262 3rd Edition — December 1999. JSON — текстовый формат, полностью независимый от языка реализации, но он использует соглашения, знакомые программистам C-подобных языков, таких как C, C++, C#, Java, Javascript, Perl, Python и многих других. Эти свойства делают JSON идеальным языком обмена данными. далее…

JSON и ваше приложение



Ну так вот, обычно, получая объекты по JSON в наших приложениях мы должны подготовить инфраструктуру для их поддержки (к примеру с помощью DataContractJsonSerializer и решения на типа этого). Однако это занимает значительное время у разработчика. В связи с этим у меня появилось страстное желание поставить JSON механизмы на рельсы динамических возможностей .NET 4.0 и получать от работы с ним одно удовольствие ;)

DynamicObject



DynamicObject — Предоставляет нам простой класс, наследуясь от которого мы можем получить динамическое поведение объекта на этапе исполнения. Наследуясь от этого класса и переопределяя некоторые его методы реализуется вся основная логика необходимая нам для этого.

Если хостинг DLR и прочие прелести вас заинтересовали и вы хотите ознакомиться немного поглубже с вопросом, то можно посмотреть наше выступление здесь, а так же слайды (здесь и здесь).

К разработке



Для того, чтобы не испытывать неудобств при работе с JSON, я предлагаю воспользоваться (слить и зареференсить) решением от James Newton под названием JSON.NET, данный проект свободен и удовлетворяет всем основным требованиям работы с JSON в рамках .NET-стека (в том числе и LINQ).

Да, к тому же нам понадобится IDE, умеющая работать с .NET 4.0b1, к примеру Visual Studio 2010 Beta 1 (кстати #develop не отстает).


Создаем наше приложение, которое будет выглядеть примерно следующим образом:
string input = @"{CPU: 'Intel', Drives: ['DVD read/writer',
"
"500 gigabyte hard drive"" ]}";

dynamic computer = new DynamicJSON(input);


* This source code was highlighted with Source Code Highlighter.

И пробуем посмотреть, какие же свойства обнаружатся у нашего компьютера:

>> computer.CPU
"Intel"

>> computer.Drives
[
"DVD read/writer",
"500 gigabyte hard drive"
]

>> computer.Drives[0]
"DVD read/writer"


* This source code was highlighted with Source Code Highlighter.

Пока ничего необычного, учитывая, что мы не знаем, что же из себя представляет DynamicJSON, к реализации которого мы и обратимся за впечатлениями:

using Newtonsoft.Json.Linq;

public class DynamicJSON : DynamicObject
{
private JObject _data;

public DynamicJSON(string data)
{
_data = JObject.Parse(data);
}

public override bool TryGetMember(GetMemberBinder binder, out object result)
{
result = _data[binder.Name];
return true;
}
}


* This source code was highlighted with Source Code Highlighter.

И это всё, что потребуется от нас для работы данного примера, меня подобные вещи радуют чрезмерно, в связи с чем рекомендую и вам использовать подобную практику в своих решениях.
Если кому-то интересна тема грядущего DLR, могу рассказать поглубже, оставляйте фидбек
+12
21 сентября 2009, 11:30
23

комментарии (16)

0
sse #
>> JSON — удобный для чтения и написания как человеком
Что-то вы тут перебрали :) Xml читается куда легче, чем json, даже при наличии <>

Вопрос по теме — какой практический смысл в этом вне консоли REPL?
0
butaji #
>> Что-то вы тут перебрали :) Xml читается куда легче, чем json, даже при наличии <>
На любителя ;) текст не мой, а по ссылке; по этому вопросу мне больше нравится YAML

Применение:
1. Прототипирование (уже после REPL)
2. Писать обертки для всего что имеет более менее динамический характер (+тот же COM)
0
sse #
2. Я не про dynamic — известно, как его MS позиционирует; я про dynamic+json
0
butaji #
как-то просто всё это («динамическая сериализация из JSON») получилось (я думал, что будет проект на пару KSLOC), что настроение подняло неимоверно

а этот код я использую в своём приложении про железяки компьютерные, пока не коммерческом (хотя, почему бы и нет)
+1
dsCode #
> Что-то вы тут перебрали :) Xml читается куда легче, чем json, даже при наличии <>

Вопрос привычки. XML в отличии от JSON перегружен ненужными скобками, атрибутами с кавычками, знакми «равно» и т.д. Хотя, парсер для XML-подобных языков писать легче, он стандартизован и один на всех.

JSON — легче по трафику для передачи.

Также, есть ещё YAML, который ещё легче JSON-a.
0
sse #
Вы, что ли, не читаете, когда ответ пишете; мне непонятно.
Я же не спрашиваю, легче он или нет. Я указываю на то, что более-менее крупный json читается человеком гораздо сложнее, чем аналогичный xml; на это и указал.
Спорить о том, что проще передавать желания нет — у меня, например, весь xml сжимается zip, так что разница все равно минимальной будет; но это же не показатель.
0
dsCode #
> Вы, что ли, не читаете, когда ответ пишете; мне непонятно.

a?

> Я же не спрашиваю

ну, тогда можете проигнорировать мой ответ. Я отметил абстрактно.

> Я указываю

да что Вы? ;)

> на то, что более-менее крупный json читается человеком гораздо сложнее, чем аналогичный xml; на это и указал.

локальная привычка, не более; как вариант, повторю, посмотрите в сторону YAML, тот ещё легче читается.
+1
sse #
Прошу прощения; довольно грубо получилось. Не выспался, наверное :)
+3
proxor #
Это нетривиальный вопрос. Хорошо отформатированный JSON читается легко, гораздо легче XML, да и редактировать его проще. С другой стороны XML проще для представления структуры данных, особенно иерархической, но перегружен скобками и тегами, создающими визуальную мишуру и усложняющими редактирование. Сравнивать надо не читабельность, а удобство работы. JSON существенно удобнее.
+1
moiseev #
А какой тип будет у computer.CPU и тем более computer.Drives? Понятно, что возвращаться они будут object'ами, а если GetType сделать?
Я так понимаю, что REPL от IronPython'а — он то всё пережуёт, а вот как с этим в C# работать — большой вопрос.
0
SunexDevelopment #
На мой взгляд, привязывайсь к .NET Framework сейчас, Вы рискуете остаться без пользователей Вашего ПО, потому что они так и не смоги запустить его на своих компьютерах (насколько мне известно, Framework 4 находится в стадии Beta 1). И привязываться к нему ради вызова variable.Params вместо variable[«Params»], имхо, опять же, не дальновидно
+1
apok #
Смею высказать своё дальновидное мнение. Вот аргументы:
1) Так говорили и про 1-ый, 2-ой и т.д. фреймворки.
2) Речь тут идет скорее о том, чтобы присматриваться (внимательно), привязываться пока рано.
3) В последнее время десктопных приложений становится меньше и меньше, так что очень вероятно, что эти новшества будут использоваться на серверах, пользователям ничего ставить не придется.
4) Приложения для предприятий, программы для использования внутри компаний… это я к тому, что не каждая программа написанная на .NET потенциально будет использоваться «щирокой» аудиторией.
Хоть я сам до сих пор использую для разработок 2.0 версию, к 4-ой таки присматриваюсь, причем без боязни.
0
SunexDevelopment #
Если мыслить в этом разрезе, согласен с Вами
0
kem #
Интересно, какая при всем при этом будет производительность?
+1
Shchvova #
Долго — долго писал на C++. Недавно ришлось часть писать на C# ( до-диез? :).
Сперва показался неплохим языком. Удобная библиотека, куча приятностей. Но только мне кажеться что он становиться сильно перегруженным, даже с синтаксической точки зрения. Ну я вообще не про то.
Разве си шарп это не язык со строгим типировпнием? По моему вся эта бадяга сильно портит уверенность в своем коде. Хочешь динамичности — питон. Там это куда лучше, приятнее и главное к месту.
Я понимаю что к статье мой коммент не имеет отношения, и автор только описал что уже есть, но может мне кто скажет, «зачем»?
+1
Shchvova #
Это я в основном о том, что предпочитаю исправлять ошибку о неправильном имени мембера сразу после того как точку с запятой поставил, а не во время рантайма.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.