Лучшая программная практика: словарь или синхронизированные массивы

Question

Я хотел знать, что лучше, или если есть больше возможностей. Я извлекаю данные из базы данных и, например, мне нужно хранить IDS и NAMES. Лучше хранить их на разных массивах тетив индексов «синхронизирована», например (Vb.net):

Dim ids As New List(Of Integer)() 
Dim sCods As New List(Of String)() 

For each elem In dataBaseData 
    ids.Add(CInt(elem("id"))) 
    sCods.Add(elem("cod").ToString()) 
Next 

Так что я знаю, что идентификатор по индексу на 3-й позиции соответствует одному и тому же индексу на другой массив. Или лучше:

Dim sCods As New Dictionary(Of Integer, String)() 

For each elem In dataBaseData 
    sCods.Add(CInt(elem("id")), elem("cod").ToString()) 
Next 

А теперь предположим, что мне также нужно хранить подэлементы. Я имею в виду, для каждого идентификатора, список элементов, так что со словарями будет что-то вроде:

Dim sSubs As New Dictionary(Of Integer, List(Of String))() 

И с массивами просто:

Dim sSubs() As New List(Of String)() 
Dim sOneSub As String = sSubs(idIndex)(subIndex) 

А потом представьте, есть много данных, извлекаемых , Я поместил свои примеры в Vb.Net, но есть только примеры.

Answer 1

Было бы плохой практикой хранить данные в отдельных «синхронизированных массивах», как вы описали. Есть много причин, почему это было бы неплохо:

• Это не самодокументирующимся - Там нет ничего очевидно, о структуре кода, который подразумевает, что пункт 3 в одном массиве хранит данные о том же объекте как элемент 3 в другом массиве. Таким образом, единственный способ сделать это очевидным - добавить комментарии к коду, объясняющему, как и почему хранятся данные. Хотя комментарии, безусловно, хорошо, но не нужны комментарии еще лучше.

• Вы не можете легко ссылаться на данные - Как вы собираетесь возвращать эти данные со своего уровня доступа к данным? Как вы собираетесь передать его как параметр методу бизнес-уровня? Чтобы получить все данные, вам нужно будет передать все списки. Чтобы передать данные одного объекта из списков, вам необходимо передать все данные в виде отдельных переменных.

• Это не является гибким - Когда вы храните его таким образом, очень сложно добавить новые объекты к объектам. Например, прямо сейчас вам может потребоваться только сохранить идентификатор и описание для каждого объекта, но что произойдет, когда вам нужно также сохранить дату? Вам не только понадобится добавить новый список/массив для хранения дат для всех загруженных объектов, но вам придется исправить всюду, которая использует и передает данные. И как вы находите все места в коде, которые вам нужно исправить? Это тоже будет непросто сделать, поскольку для объекта, который вы можете искать, нет определенного типа данных.

• Это хрупкое - По всем причинам, упомянутым выше, и т. Д., Хранение таких данных приведет к ошибкам кода. Что произойдет, если списки не синхронизируются? Что произойдет, если вы не сможете загрузить данные на полпути через объект, так что только некоторые из списков обновляются? Что делать, если вам нужно удалить элемент из списка, и по какой-либо причине он выходит из строя только по одному из списков? Что делать, если несколько потоков должны изменять данные одновременно? Если вы не очень осторожны, все может пойти не так просто. Нет необходимости делать так, чтобы ваш код был хрупким, так почему бы вам без лишних хлопот?

Итак, какое лучшее решение?Ну, Dictionary определенно лучший вариант, но в этом случае он все еще может быть ошибочным. Вам не нужен словарь, если вам нужно всего лишь хранить два элемента данных на один объект. Цель словаря - хранить пары ключ/значение, где вам нужно быстро получить доступ к значению, данному ключу. Словарь использует хеш-таблицу для индексации списка, чтобы сделать ключевые поиски очень быстрыми. Но если он не используется должным образом, он может фактически сделать вещи менее эффективными (а именно, больше памяти, медленнее из-за генерации хеш-кода).

Правильный способ хранения данных для объекта или объекта, как его иногда называют в дизайне БД, заключается в создании класса. Эти классы часто называются классами передачи данных (DTO). Например:

Public Class MyEntity 
    Public Property Id As Integer 
    Public Property Code As String 
End Class 

Затем, вы можете легко хранить данные в любом типе списка, который вы хотите, например:

Dim entityArray() As MyEntity ' Arrays are great for storing lists which don't change in length very often 
Dim entityList As List(Of MyEntity) ' Lists are great when the number of items in the list keeps changing 
Dim entityDictionary As List(Of Integer, MyEntity) ' Dictionaries are great when you need to quickly access items by their key (their ID, in this case) 
Dim entityQueue As Queue(Of MyEntity) ' Queues are great when you need to process incoming items in the order that they were received 
' Etc. 

Теперь, когда вам нужно вернуть MyEntity объект, вы можете вернуть его As MyEntity. И когда вам нужно вернуть их список, вы можете вернуть их в виде единого списка. То же самое верно при передаче их в качестве параметров методам.

Кроме того, когда вам нужно добавить новое свойство в вашей организации, вы можете просто добавить его в свой класс DTO, как это:

Public Class MyEntity 
    Public Property Id As Integer 
    Public Property Code As String 
    Public LastModified As Date ' Hey look! A new field. 
End Class 

Теперь весь код, который работает с этим типом данных будет все мгновенно имеют доступ к этому новому свойству. Все, что вам нужно сделать, это заполнить поле данными. Если вы хотите найти все места в своем коде, которые работают с этим типом данных, просто щелкните правой кнопкой мыши по имени класса MyEntity и выберите опцию Найти все ссылки из контекстного меню.

Как уже упоминалось, существуют рамки для создания классов сущностей и чтения и записи их в базу данных. Я бы сказал, что в то время, когда я пишу это, Entity Framework и NHibernate являются двумя самыми популярными опциями. Они, безусловно, заслуживают внимания, но всегда важно понять, что делает инфраструктура и почему она вам нужна, прежде чем вы начнете ее использовать. Поэтому я бы рекомендовал, по крайней мере, попытаться сделать ваши слои доступа к данным должным образом на некоторое время, прежде чем вы начнете искать способы разрезать углы. Нет ничего плохого в использовании фреймворков, которые упрощают вашу жизнь, но если вы используете какую-либо структуру неправильно или по неправильным причинам, они, вероятно, затруднят вашу жизнь, а не проще.