Рейтинг:
0
Sergey Alexandrovich Kryukov
Пожалуйста, смотрите: https://sixgun.wordpress.com/2012/02/09/using-json-net-to-generate-jsonschema[^].
Вы должны понимать, что генерация метаданных из данных может быть неоднозначной; это зависит от того, насколько репрезентативна ваша выборка данных.
[РЕДАКТИРОВАТЬ]
Мой последний абзац выше предполагает, что этот подход может не иметь большого смысла; это зависит от ваших целей, которые вы не разделяли с нами.
Я бы предложил альтернативный подход. Вы можете использовать JSON только через контракт данных:
https://msdn.microsoft.com/en-us/library/ms733127%28v=vs.110%29.aspx[^],
https://msdn.microsoft.com/en-us/library/system.runtime.serialization.json.datacontractjsonserializer%28v=vs.110%29.aspx[^].
Как это связано со схемой? Я все объясню. Сериализатор, на который ссылаются, как и любой другой сериализатор, основанный на контракте данных и большинстве других сериализаторов, основан на отражении.
Когда в своем комментарии Вы спрашиваете о "классе", это не всегда может быть класс; как правило, это набор связанных типов, поэтому их экземпляры образуют один связанный граф данных Сериализация-это инструмент, который дает вам возможность сохранить этот график в потоке, а затем восстановить его из потока таким, как он есть.
Вы уловили идею?
Вам нужно использовать отражение классов данных, составляющих контракт, чтобы перевести структуру контракта в эквивалентную форму схемы JSON. По сравнению с полноценным сериализатором, который у вас уже есть из .NET FCL, это относительно простая задача. Почему? Потому что" реальный " сериализатор использует System.Reflection.Emit
для создания сборки сериализации необходимо повторно использовать код сериализации по соображениям производительности. Обычно вы сериализуете схему (метаданные) гораздо реже, чем данные, поэтому вы позволяете себе игнорировать производительность (что также было бы достаточно хорошо; потому что схема не может быть слишком большой, чтобы представлять проблему, но данные могут быть). Используйте только System.Reflection
м не излучают и просто создать схему JSON-строку из .Объем метаданных.
—СА
eagers
спасибо Сергею Александровичу Крюкову за ответ, в этой ссылке техника заключается в использовании класса existance для генерации схемы, но моя цель-сгенерировать ее из файла данных. кстати, спасибо.
Sergey Alexandrovich Kryukov
Извините, но я не вижу большой разницы.
—СА
Sascha Lefèvre
Сергей, я думаю, что вы либо неправильно поняли его вопрос, либо разместили другую ссылку, чем намеревались. Ссылка не решает его проблему.
/Саша
Sergey Alexandrovich Kryukov
Может быть, я неправильно понял материал в моей ссылке, но я думаю, что понял вопрос.
Вообще, я несколько негативно отношусь к идее генерации метаданных из образцов данных.
Теперь, пожалуйста, посмотрите мое альтернативное предложение после [EDIT].
—СА
eagers
я работаю над программой, которая во время выполнения генерирует класс для файлов данных Json. таким образом, существует только файл данных, мой план-Шаг 1: создать схему json. Шаг 2: Создайте несколько классов для него во время выполнения, поэтому я думаю, что эта ссылка не может мне помочь, но если вы видите что-то, чего я не могу, пожалуйста, объясните это.
Sergey Alexandrovich Kryukov
Вы можете, но ценность этой работы может быть сомнительной, потому что это двусмысленный путь. Зачем вообще создавать классы и схемы из образцов JSON? Я имею в виду, что сомневаюсь в самой идее. Если вы можете поделиться своими конечными целями,мы можем обсудить это.
—СА
eagers
спасибо Сергею за ответ. Конечная цель - это программа buider, чтобы ее входные данные не зависели от какого-либо типа данных, все данные можно было обрабатывать в реальном времени. связь между уровнем данных и уровнем представления может быть определена метаданными. я хочу, чтобы программа и входные данные были независимыми.
eagers
я видел класс DataContractJsonSerializer, но все конструкторы нуждаются в типе, считайте, что мы не знаем о типе файла данных, мы знаем только, что это хорошо известный JSON-файл. да, я согласен с вами, что в конце концов у нас есть не класс, а набор связанных типов.
Sergey Alexandrovich Kryukov
Я предлагаю вам изменить ситуацию. Делает типы контракта данных известными, а файлы JSON и схема делают что-то промежуточное.
Хорошо, я много работал в области программирования на основе метаданных, разрабатывал целые технологии и методологию на основе метаданных и довольно хорошо знаю эту область. Собираетесь ли вы выразить метаданные в виде схемы JSON? Это можно считать. Но файл данных JSON - плохой кандидат на роль источника метаданных. Это связано с тем, что JSON основан на JavaScript, языке со свободной парадигмой типизации. И .NET использует парадигму строгой типизации. Сериализатор идеально сериализует граф данных .NET и десериализует его на основе строгой типизации. Зачем? потому что метаданные извлекаются из сборки с помощью отражения, которое также представляет метаданные строгого типа.
Мне начинает казаться, что ты не совсем понимаешь, куда лезешь. Если вы выберете сомнительный способ, это будет настоящая банка грелок, от которой будет трудно избавиться.
Одним из подходов может быть изобретение собственного языка, представляющего метаданные .NET (например, для чистых структур данных). Даже если вы можете использовать XML или JSON для сохранения схемы метаданных, это не должна быть схема XML или JSON; это будет схема, представляющая вашу точную модель. Вы можете ограничить свои структуры данных определенным фиксированным числом примитивных типов (+строки +типы перечисления) и определенным подмножеством структурных типов (скажем, классы только со свойствами данных, типы которых ограничены вашим набором примитивных типов).
Противоположным подходом может быть моделирование вашей системы свободного набора текста JavaScript в .NET, что также вполне возможно.
—СА
eagers
Спасибо Сергею за ответ и хорошее детство. В моей модели у меня есть 3 Раздела I:Froms, II:Data и III: Events and Actions. Для раздела метаданных у меня есть самостоятельно созданная ограниченная структура, которая может объяснить связь между этими тремя частями.
Часть III-это почти статический раздел, в котором все мои действия и события предопределены заранее. но два других оставшихся раздела (I и II) являются динамическими. В Части II (раздел данных) моя цель состоит в том, что все данные в форматах xml или json без каких-либо ограничений могут быть переданы программе, затем определяется структура данных во время выполнения и генерируется соответствующий тип данных, и все данные хранятся на нем, после чего метаданные определяют, как эти данные взаимодействуют с формами. я думаю, что ваше мнение таково: раздел II должен быть статическим, и у меня есть только предопределенный тип, такой как T. Так как же я достигаю цели охватить все типы данных? преобразовать их в предопределенный тип T?
Sergey Alexandrovich Kryukov
Боюсь, я не хотел сказать, что раздел II должен быть статичным (что вы имеете в виду?), Просто потому, что я недостаточно хорошо знаком с вашей архитектурой. Похоже, вы занимаетесь интересной работой и у вас есть хорошие идеи. Тем не менее, я также считаю, что медатада и постоянное представление метаданных и данных требуют большего размышления. Я попытался объяснить некоторые проблемы, с которыми вы столкнетесь. Моя идея такова: вы должны приступить к архитектурным вопросам и постановке проблем, а не сразу переходить к решению проблемы. Проблема, которую вы пытаетесь решить в исходном вопросе, не та, которую вы должны иметь. Вы переходите от общих архитектурных проблем к конкретным; и советую подумать о том, чтобы избежать этого заблуждения ...
—СА