Один способ создания нескольких объектов или нескольких методов для создания отдельных объектов?

Question

Если у меня есть следующий:

Public Class Product 
    Public Id As Integer 
    Public Name As String 
    Public AvailableColours As List(Of Colour) 
    Public AvailableSizes As List(Of Size) 
End Class 

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

1. есть один метод (GetProducts()), который использует единственное представление, которое объединяет соответствующие таблицы, которые затем проходят через каждую строку и создают объекты по мере необходимости? Или ...
2. Есть несколько методов, которые отвечают только за создание одного объекта каждый? например. GetProducts(), GetAvailableColoursForProduct (идентификатор), и т.д.

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

Answer 1

Вы, вероятно, лучше всего сравниваете и то, и другое. Я видел ситуации, когда просто выполнение нескольких запросов (MySQL это нравится) быстрее, чем JOINs и один большой медленный запрос, который занимает много памяти и заставляет сервер БД превзойти. Я говорю об этом, потому что он будет зависеть от вашего сервера базы данных, от того, сколько памяти и параллельных подключений у него есть, размеров ваших таблиц, оптимизации ваших индексов и размера ваших типичных наборов записей. ПРИСОЕДИНИТЕСЬ на больших неиндексированных столбцах очень дорого (так что вы должны либо не делать их, либо добавлять индексы).

Возможно, вы также узнаете немного больше/будьте более удовлетворены в конце, если вы напишете хотя бы немного обеих реализаций (вам не нужно писать методы, просто кучу тестовых запросов), а затем контрольные , а не просто с тем или другим. Самая сложная (но важная) часть тестирования - это одновременное одновременное одновременное использование одновременных пользователей БД - реалистичная производственная память и загрузка процессора.

Имейте в виду, что вы имеете дело с 2-мя проблемами: Один из них - проблема с DBA, как я могу сделать это быстрее и эффективнее. Второй - программист, который хочет красивого, поддерживаемого кода. (b) делает ваш код более читабельным и расширяемым, чем просто гигантские запросы со сложными JOIN, поэтому вы можете предпочесть его (а), если он не будет значительно медленнее.

Answer 2

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

Answer 3

У вас есть это. Решение b не будет масштабироваться, поэтому решение a является ключевым, поскольку производительность вызывает беспокойство. К тому же, почему вы должны ограничивать метод GetProductDetails(), чтобы захватить все данные в одном запросе (следовательно, подход SQL)? Почему нет этого метода выполнить 3 запроса и прощаются с вашей грязной логикой:

• Один для идентификатора и поиска имени
• Один для цветов списка
• Один для списка размеров

В зависимости на используемом вами SQL-процессоре эти три запроса могут быть сгруппированы в один пакетный запрос (один раунд) или потребуются 3 повторных поездки. При добавлении дополнительных свойств в ваш класс вам придется решить, следует ли улучшить первый запрос или добавить новый.

Answer 4

В случае выше, я бы, вероятно, просто один статический метод нагрузки, особенно если все или большинство свойств, как правило, необходимое:

Public static function Load(Id as integer) as Product 

Product.Load(Id) 

Если говорить свойство цвета rarly используется и довольно дорого для загрузки то вы можете все еще использовать выше, но не нагружать свойство цвета оттуда, но динамически загружать его из геттера так:

private _Colors as list(Of Color) 
public property Colors() as List(Of Color) 
    get 
     if _Colors is nothing 
      . .. . load colors here 
     end if 
    end get. . . . . 

Answer 5

Go для опционной б) он делает свои атрибуты независимо от представления данных (например, таблица)

Я думаю, вам будет полезно узнать больше о MVC-Architecture.Он обозначает M odel (Ваши данные -> Продукт), V iew (Презентация -> Таблица) и C ontroller (новый класс, который будет собирать данные из модели и обрабатывать его для вывода View)

Confused? Это не так сложно. На каком языке находится ваш фрагмент кода? Многие Framework, такие как Ruby on Rails, Java Struts или CakePHP, практикуют это разделение слоев Программы.

Answer 6

b будет более быстрым (с точки зрения производительности) при чтении вашей установки, но при обновлении вашего класса потребуется обновление кода обслуживания (обновление каждой функции).

Теперь, если производительность - это ваша истинная цель, просто сравните ее. Напишите как a, так и b, загрузите свою БД несколькими (сотнями) тысяч записей и тестов. Затем выберите лучшее решение. :)

/Вея

Answer 7

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

Если вы делаете рефакторинг, я бы предложил ввести factory pattern в ваш код. Заводская модель управляет созданием сложных объектов и позволяет скрыть детали построения объекта из кода, который потребляет объект (ваш пользовательский интерфейс в этом случае). Это также означает, что по мере усложнения вашего объекта потребители будут защищены от изменений, которые могут потребоваться для управления сложностью.

Answer 8

Вы должны изучить АктивРекорд CastleORM, который работает сверху NHibernate. Вы разрабатываете модель данных (например, вы сделали с «Продуктом»), которая наследуется от базового класса AR, что обеспечивает отличные возможности запросов. AR/NHibernate обеспечивает агрессивную оптимизацию запросов и кэширование. Проблемы с производительностью и масштабируемостью могут исчезнуть. По крайней мере, у вас есть достойная рамка, в которой можно настроить. Вы можете легко разделить свои модели данных до теста B.