Избегайте множества запросов GET к БД в PHP OOP

Question

Я создаю простую контактную форму в PHP OOP. У меня есть 2 класса - константы со всеми глобальными константами и Message, который обрабатывает вещи, связанные с отправкой / отображением сообщений.

И здесь у меня проблема. Я мог бы сделать это легко, но я хочу избежать выполнения нескольких запросов, чтобы получить конкретные c данные о сообщении, такие как автор, ip или текст. И я вижу 2 решения - выбрать все данные из БД в конструкторе моего класса Message или создать новый метод, например, getAllData (), и использовать его только один раз.

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

Так, возможно, я должен сделать 2 класса вместо 1? SendMessage и ShowMessage. Но можно ли так использовать классы?

Answer 1

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

Где Измеримая стоимость в обоих подходах? То, что я вижу, это сложность кода и производительность. Для извлечения всех данных (в агрегатный объект) требуется на пару строк кода меньше, чем для извлечения указанных c значений - на самом деле этого недостаточно, чтобы стать решающим фактором. Поскольку известно, что данные являются небольшими (то есть не тысячами элементов данных или более), тогда нет существенных накладных расходов на хранение всех данных в PHP после их извлечения, если они никогда не используются - опять же, нет ясных аргумент в любом случае. Но стоимость извлечения данных зависит от количества циклов, которые поток выполнения выполняет с базой данных, и это делает извлечение всех данных в одну горячую среду намного более эффективным (по крайней мере, для баз данных типа MySQL, это также значительно лучше для кеширования СУБД).