Избегайте загрузки ненужных данных из БД в объекты (веб-страницы)

Question

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

Например, допустим, у вас есть таблица Article, содержащая поля id, title, author, date, summary и fullContents. Вам не нужно загружать fullContents в связанные объекты, если вы просто показываете страницу, содержащую список статей с их резюме. С другой стороны, если вы отображаете конкретную статью, вам может потребоваться загрузить каждое поле для этой одной статьи и, возможно, только заголовки для других статей (например, для отображения на боковой панели последних статей).

Некоторые техники, которые я могу придумать:

1. Не беспокойтесь, просто загружайте все из базы данных каждый раз.
2. Имейте несколько разных, возможно унаследованных, классов для каждой таблицы и создайте соответствующий класс для ситуации (например, SummaryArticle, FullArticle).
3. Используйте один класс, но присвойте неиспользуемым свойствам значение null при создании, если это поле не требуется, и будьте осторожны.
4. Предоставьте объектам доступ к базе данных, чтобы они могли загружать некоторые поля по требованию.
5. Что-то еще?

Все вышеперечисленное, похоже, имеет довольно серьезные недостатки.

Я довольно новичок в программировании, очень плохо знаком с ООП и совершенно новичок в базах данных, поэтому я мог бы упустить очевидный ответ. :)

Answer 1

(1) Загрузка всего объекта, к сожалению, по умолчанию выполняется ORM. Вот почему вручную настроенный SQL работает лучше. Но большинство объектов не нуждаются в этой оптимизации, и вы всегда можете отложить ее на потом. Не оптимизируйте преждевременно (но пишите хороший SQL / HQL и используйте хороший дизайн БД с индексами). Но по большому счету проекты ORM, которые я видел, привели к большому количеству ленивых подходов, извлекающих или обновляющих намного больше данных, чем необходимо.

2) Различные модели (объекты), в зависимости от операции. Я предпочитаю этот. Может добавить больше классов к объектной области, но для меня это наиболее чистый и приводит к повышению производительности и безопасности (особенно если вы сериализуете в AJAX). Иногда я использую одну модель для сериализации объекта клиенту, а другую - для внутренних операций. Если вы используете наследование, вы можете сделать это хорошо. Например, CustomerBase -> Клиент. CustomerBase может иметь идентификатор, имя и адрес. Клиент может расширить его, чтобы добавить другую информацию, даже такие вещи, как пароли. Для операций со списком (список всех клиентов) вы можете вернуть CustomerBase с пользовательским запросом, но для отдельных операций CRUD (Создать / Получить / Обновить / Удалить) используйте полный объект Customer. Даже тогда будьте осторожны с тем, что вы сериализуете. Большинство фреймворков имеют белые списки атрибутов, которые будут и не будут сериализованы. Используйте их.

3) Опасные, особые случаи могут вызвать ошибки в вашей системе.

4) Плохо для производительности. Ударьте по базе данных один раз, не для каждого поля (кроме BLOB).

Answer 2

Из вашего списка, варианты 1, 2 и 4, вероятно, наиболее часто используемые.

1. Не беспокойтесь об этом, просто загружайте все из базы данных каждый раз: Что ж, если ваше приложение не находится под большой нагрузкой или у вас в таблицах слишком тяжелые поля, используйте эту опцию и избавьте себя от необходимости разбираться что-то лучше.

2. Имейте несколько разных, возможно унаследованных, классов для каждой таблицы и создайте подходящий для ситуации (например, SummaryArticle, FullArticle): Такие классы часто называют «моделями представления» или чем-то подобным, и в зависимости от вашей стратегии доступа к данным Вы можете получить доступ к таким объектам без объявления какого-либо нового класса. Например, используя Linq-2-Sql, выражение data.Articles.Select(a => new { a .Title, a.Author }) даст вам набор анонимно типизированных объектов со свойствами Title и Author. Сгенерированный SQL будет похож на select Title, Author from Article.

4. Предоставьте объектам доступ к базе данных, чтобы они могли загружать некоторые поля по требованию: Объекты, которые вы здесь описываете, обычно называются «прокси-объектами» и / или их свойства называются «загруженными с отложенным доступом». Опять же, в зависимости от вашей стратегии доступа к данным, создание прокси может быть трудным или легким. Например. с NHibernate вы можете иметь ленивые свойства , просто добавив lazy=true в ваше отображение, и прокси будут автоматически созданы.

В вашем вопросе не упоминается, как вы сейчас отображаете данные из своей базы данных в объекты, но если в данный момент вы не используете какой-либо фреймворк ORM, взгляните на NHibernate и Entity Framework - они оба довольно солидные решения.

Answer 3

У вас есть несколько способов решить вашу проблему.

1. Используйте хранимые процедуры в вашей базе данных, чтобы удалить ненужные строки или столбцы. Это может отлично работать, но занимает немного места.
2. Используйте ORM какого-нибудь рода. Для .NET вы можете использовать Entity Framework, NHibernate или Subsonic. Есть много других инструментов ORM для .NET. В Ruby это встроено в Rails. Java использует Hibernate.
3. Пишите встроенные запросы на вашем сайте. Не забудьте параметризировать их, иначе вы откроете себя для хакеров. Эта опция обычно не одобряется из-за смешения SQL и кода. Также его легче всего сломать.