.NET Object Design

Question

У меня есть ряд объектов, которые я создал:

Пункт

Заказать

Песня

и т.д.

Каждый объект имеет разумное количество свойств, и я использую средство чтения данных, где я передаю его «SELECT * FROM .objectname». а затем я заполняю коллекцию объектов и возвращаю коллекцию. Это работает так: GetOrdersCollection (), GetSongsCollection () и т. Д.

Я понимаю, что SELECT * является проблемой производительности, и, кроме того, иногда я предпочитаю включать в оператор select дополнительные столбцы, которых нет в объекте, и которые также возвращают все эти значения.

Итак, мой вопрос: как лучше всего подойти к этой проблеме?

1. Должен ли я создавать новый объект для каждого типа запроса?

2. Я попытался выполнить проверку, чтобы увидеть, находится ли столбец в datareader перед его сохранением, но это представляет перфект. проблемы. Есть ли незначительный перф. способ избежать IndexOutOfRange?

3. Должен ли я просто использовать Datatable и читать прямо из таблицы?

Answer 1

Я понимаю, что SELECT * проблема производительности,

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

1.Можно ли создать новый объект для каждого типа запроса?

Вы должны создать новый объект для каждой таблицы и новый метод для каждого типа запроса.

2.Я попытался выполнить проверку, чтобы увидеть, находится ли столбец в datareader перед сохранением это, но это представляет перф. проблемы. Является там ничтожный перф. способ избежать IndexOutOfRange

Если вы ссылаетесь на свои поля по имени, а не по индексу, проблем IndexOutOfRange не должно быть. Если вы ссылаетесь на свои поля по индексу, вы можете циклически проходить по ним, где ваш индекс меньше столбца Count (), и не должно быть никаких проблем IndexOutOfRange.

3. Должен ли я просто использовать Datatable и читать прямо из таблицы?

Это очень хороший подход для начала. Подумайте о том, чтобы потратить некоторое время на изучение простого ORM, как предлагали другие. Subsonic - хороший "первый" ORM.

Answer 2

Есть ли причины, по которым вы не можете использовать простой генератор ORM, например SubSonic ? Это позволит вам очень легко получить доступ к этим типам коллекций, и они будут строго типизированы. Вам также не придется беспокоиться о SQL, так как запросы будут создаваться SubSonic.

Answer 3

Чтение с точки зрения производительности из прямой структуры данных, такой как DataReader, обеспечит вам наилучшую производительность и сохранение ресурсов.

С другой стороны, заполнение объекта (как это делает OR / M) может быть незначительным, если вы не возвращаете больше, чем горстку объектов.

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