Является ли излишним помещать операторы выбора MySQL в класс и операторы CRUD в дочерний класс?

Question

У меня есть 2 класса для доступа к базе данных:

MovieDAO - доступ к базе данных только с помощью операторов «select»; Цель - получить данные для отображения в веб-браузере.

и

MovieExtendedDAO (расширяет MovieDAO) - который является более полным и позволяет создавать / обновлять / удалять фильмы в дополнение к унаследованной функциональности. Этот класс предназначен для использования только в административной области сайта.

Мне сказали, что разлучать, как это, излишне.

Это нормальный способ делать вещи или часть шаблона проектирования? Или нет никакой реальной выгоды для этого? Моим основным намерением было упростить вещи для публичной стороны: своего рода оптимизация того, сколько вещей нужно загрузить, а также какие вещи могут происходить на публичной (не администраторской) стороне. Спасибо за ваши комментарии!

Answer 1

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

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

Answer 2

это не плохой метод, это в основном строка данных . в этом смысле я думаю, что ваш movieDAO - это скорее средство поиска (та же терминология, которую использует Фаулер), а ваш фильм расширенный как шлюз (т. е. MovieFinder и MovieGateway).

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

Answer 3

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

Относительно разрешений - это то, что должно быть логикой приложения, а не физически разделять методы на разные классы. Кроме того, разве вы не расширяете базовый DAO, который абстрагирует такие операции? Вы не будете внедрять отдельные методы вставки / удаления / обновления для каждой модели? эти операции не сильно различаются и должны принадлежать общему родительскому классу.

Я предлагаю вам взглянуть на некоторые хорошие реализации с открытым исходным кодом для абстракции базы данных в PHP, такие как Zend_Db (которые я настоятельно рекомендую).

Answer 4

Основная проблема, которую я вижу здесь, заключается в том, что вы смешиваете разрешения (Control) с доступом к базе данных (модель). Я иду против архитектуры Модель - Представление - Контроллер , но нет, я не говорю, что все должны использовать ее. Это своего рода сложная модель. Это может иметь преимущества перед вашим решением. Влияет ли изменение ваших прав доступа на модель вашего класса? Я так думаю.

В приложении MVC могут быть и другие способы контроля доступа. В базе данных (например, по пользователям).