Список всех музыкальных файлов в каталоге с их информацией

#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.