#c# #.net #json #wmp
#c# #.net #json #wmp
Вопрос:
Я создаю приложение, которому необходимо создать сериализацию JSON всей музыкальной библиотеки. Это нужно делать только при каждом изменении музыкальной библиотеки (это сервер, и музыка отправляется авторизованным клиентам по запросу).
Я знаю, что вы можете получить информацию о музыке, выполнив следующее
IWMPMedia3 song = new IWMPMedia3();
string artist = song.getItemInfo("Artist");
//etc for other elements (title, album)
Итак, мне интересно, могу ли я использовать это для заполнения списка JSON таблицами, подобными таким:
"Songs":{ "Artist1":{
["Album1":{"song1":"title", "song2":"title"}
, "Album2"]},
"Artist2"{["Album1", "Album2"]}}
Или аналогичный. Если у вас есть лучший способ сделать это, я, безусловно, открыт для конструктивной критики.
Комментарии:
1. Ваш JSON неверен — вы можете обновить свой пример?
Ответ №1:
Самый простой и удобный способ изменить данные подобным образом — сначала загрузить их в обычное старое объектное представление, а затем использовать это для сериализации вашего вывода.
В вашем конкретном случае вы, вероятно, захотите определить форму ваших классов, чтобы отразить JSON, который вы хотите создать, например,
class AllSongs { public Artist[] Artists; }
class Artist { public string Name; public Album[] Albums; }
//etc...
В более сложных случаях вам может потребоваться два (или редко даже больше) таких представления — одно, которое легко сопоставляется с вводом, и другое, которое легко сопоставляется с выводом. Это позволяет упростить преобразование кода между двумя представлениями.
Эти чрезвычайно тривиальные классы иногда известны как объекты значений или объекты передачи данных. В C # вы можете преобразовать объект в из JSON с помощьюJSON.net — нет необходимости загружать его вручную, просто добавьте ссылку с помощью nuget.
Кстати, я бы не стал использовать этот тип вложенности «Исполнители» > «Альбомы» > «Песни», потому что это сложнее, чем необходимо, и потому что некоторые люди, возможно, хотят другое представление (скажем, по году или десятилетию, или в алфавитном порядке по названию песни, или по количеству воспроизведений и т.д.). Действительно простая реализация — это просто один класс Song
(или какое-то подобное имя), в котором есть все соответствующие поля метаданных. Таким образом, разные клиенты (или меняющиеся будущие потребности) могут легко группировать по любым полям, которые их интересуют, без необходимости сначала разворачивать вашу вложенность.
Комментарии:
1. Будет ли это занимать память? Если я каталогизирую более 10000 песен, приведет ли это к задержке? Кроме того, что касается идеи использования класса Song, это программное обеспечение создается для удовлетворения очень специфических потребностей меня (не планирую его выпускать).
2. 10000 песен — это не так много; давайте посмотрим наугад и предположим, что 1 КБ метаданных на песню — это все еще всего 10 МБ данных. Я пока не волнуюсь :-).
3. Итак, просто для уточнения: я бы создал эти классы (или что-то подобное) — без функций, только объявления переменных. Затем выполните итерацию по каталогам и создайте объект для исполнителя и т.д. — Затем сериализуйте его?
4. Вот и все! В общем, я советую использовать классы чистых данных (и структуры) и не чувствовать необходимости добавлять поведение везде. Совершенно нормально просто моделировать данные, когда вам нужно … моделировать данные :-). Это не значит, что вы никогда не должны инкапсулировать внутреннее состояние поведением (методами), просто не предполагайте, что вам нужно сразу. Чтобы повторить ответ, вы можете прочитать об объектах DTO / Value.