Двойная загрузка/сохранение объектов в OOPHP - ненужное дублирование?

Question

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

Я планирую подходя к нему таким образом:

• Есть набор основных объектов «Load» (например, ProjectLoad, FormLoad), которые принимают идентификатор при создании, запрос к базе данных и заполнить себя с извлеченные данные. Эти объекты затем могут использоваться для заполнения элементов страницы.

• Имейте еще один набор объектов «Сохранить» (например, ProjectSave, FormSave), которые принимают массивы (возвращаются при отправке страницы), заполняют их этими данными, а затем выполняют операции INSERT\UPDATE в базе данных.

Это лишнее дублирование? Я просто обращаюсь к OOPHP, и все советы, которые я видел до сих пор, как представляется, указывают на то, что лучше всего пытаться сохранить все (объекты, методы и т. Д.) Как можно более целенаправленные и одноцелевые. Это, похоже, соответствует этим критериям, но есть ли лучший способ?

Answer 1

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

• основная идея позади Data Mappers

• сепарации логики для создания новых записей и логики для извлечения данных (эта идея действительно важна в CQRS, особенно в контексте Event Sourcing)

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

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

«Совет, который вы видели» на самом деле называется Single Responsibility Principle и является, TBH, является одним из более туманных концепций в ООП. Это как определение, что такое «порно» это - знаете, когда вы видите его.

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

$project = new Entity\Project; 
$mapper = new Mapper\Project($pdo); 

$project->setId(43); 
$mapper->load($project); //pulls data about project 43 from DB 

if ($project->getDeadline() > time()) { 
    $project->setStatus(Entity\Project::STATUS_OVERDUE); 
    $mapper->save($project); //pushes changed state to DB 
} 

Answer 2

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

Если вы на самом деле в OOPHP вы можете также проверить темы о Design Patterns:

• OOP Design Patterns - для основных (строительных блоков) шаблонов проектирования.
• Martin Fowler's Patterns of Application Architecture - современные шаблоны проектирования

Согласно Википедии:

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