Существует ли общепринятый способ добавления метаинформации в элементы массива, указывающий, как с ними обращаться? - PullRequest
Новая
       8

Существует ли общепринятый способ добавления метаинформации в элементы массива, указывающий, как с ними обращаться?

1 голос
/ 14 сентября 2009

Я использую массив, который содержит результаты запроса к базе данных, который впоследствии форматируется как html (для веб-приложения) или как csv (для импорта в электронную таблицу). Я хочу прикрепить информацию к элементу массива, который имеет некоторую дополнительную информацию о том, как можно использовать данные этого элемента.

Например, массив-элемент-данные ...

  • ... может отображаться как ссылка: тогда я хочу прикрепить информацию о ссылке. Код, который создает HTML из массива, может использовать его для создания ссылки.
  • ... это дата вида 2009-09-14: тогда я хочу как-то пометить ее как дату. Если использование для html-страницы, то оно может быть отображено несколько более красиво, например, Пн Сен 14 или Сегодня ; если получатель - CSV, лучше оставить его.

Существует ли наилучший способ решения этой проблемы?

Я подумал о нескольких возможных решениях, но хотел спросить, знает ли кто-нибудь уже «лучшие практики». От возможно лучшего к худшему:

  1. Храните каждый элемент массива как созданный пользователем объект (Date, Linkable, Text ...), вместо того, чтобы использовать элемент массива как текст. Возможно предоставить метод по умолчанию .to_string().
  2. Сделайте каждый элемент массива хэшем, чтобы я мог сказать a[5][7]['text'] или a[5][7]['link'].
  3. Создать разные версии массива, например, textArray[5][7], linkArray[5][7]

Создание html как начала и просто использование текстовой версии кажется плохой идеей, так как внешний вид зависит от использования (например, 2009-09-14 vs Mo 14 сентября ).

Или я просто задаю не тот вопрос?

Ответы [ 3 ]

0 голосов
/ 14 сентября 2009

В качестве общего совета лучше всего, если данные вообще не содержат информации о том, как себя представлять.

Вместо этого часть приложения, создающая представление, должна иметь эти параметры в отдельной структуре данных. Думайте об этом как о файле XML и различных файлах XSLT, создающих различные представления.

Но в случаях, когда это невозможно или когда вам необходимо объединить две информации в одну структуру данных для фактического преобразования, я следовал этому практическому правилу:

Не будь умным и делай то, что естественно на твоем языке!

  • В Java и Delphi я всегда использовал вариант «пользовательский объект», потому что можно получить определенные преимущества, такие как проверка времени компиляции.
  • В PHP я всегда использовал хэши, потому что это более стиль PHP-ish.

Я иногда делал «Решение 3», но я всегда сожалел об этом. Эти структуры, как правило, становятся кошмаром обслуживания, и вы, скорее всего, столкнетесь с проблемами синхронизации с точки зрения данных, а также с точки зрения кодирования.

0 голосов
/ 14 сентября 2009

Общий подход в веб-фреймворках заключается в отображении записей на объекты: одна запись из базы данных считывается в один объект, поэтому в результате получается массив объектов. Для разных таблиц нужны разные классы. Это один из строительных блоков для шаблона Model View Controller (MVC), используемого во многих веб-фреймворках.

Например, в Ruby on Rails таблица users обрабатывается классом User. Вы создаете оба с помощью эшафот. 

ruby script\generate scaffold user lastname:string link:string joined:date

Дата, Булево, Строка, Текст, Десятичное число, Целое число - это различные типы данных. К сожалению, URL-адресов нет, поэтому я должен использовать строку для ссылки.

Вы можете читать пользователей из базы данных так: 

@u = User.find(77)       # gives you one object
@list = User.find(:all)  # gives you an array of User-objects

атрибут объекта пользователя имеет правильные типы для работы с датами, числами и т. Д .:

если 100.days.ago <@ u.joined затем .... </p>

Логика, присущая данным, реализована в классе User.

Список пользователей может отображаться в формате HTML с использованием следующего вида: 

  <h1>Listing Users</h1>
  <table>
    <tr>
      <th>Lastname</th>
      <th>Link</th>
      <th>Joined on</th>
    </tr>
  <% @list.each do |user| %>
    <tr>
      <td><%=h user.lastname %></td>
      <td><%= link_to "Homepage", user.link %></td>
      <td><%=h user.joined %></td>
    </tr>
  <% end %>
  </table>

Логика, свойственная отображению данных, реализована в представлениях. Информация о том, какой атрибут объекта следует рассматривать как ссылку или обычный текст, находится в представлении, а не в самом объекте.

Отображение / вывод тех же данных, что и в cvs, осуществляется путем создания cvs-view.

0 голосов
/ 14 сентября 2009

Если вы не укажете язык, (1) и (2) в основном одинаковы. Объект или хеш, в чем разница в динамическом языке программирования, кроме, возможно, синтаксиса? В Lua все словарь.

(1) / (2) обычно предпочтительнее (3), поскольку они, как правило, значительно облегчают копирование элемента вместе с его метаданными. При сортировке, например.

Таким образом, не привязываясь к конкретному языку / среде, лучше всего при отсутствии каких-либо особых условий как-то комбинировать метаданные и элемент и обрабатывать полученный тип данных. Вы можете сделать это, определив новый класс, который будет содержать оба, определив еще один подкласс вашего исходного типа элемента, используя общую пару, используя словарь общего назначения, или просто храня метаданные в исходном объекте (который будет очевидный подход, скажем, в Javascript).

...