Все мои модели выглядят одинаково

Question

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

class Site extends CI_Model {

    public function get_site_by_id($id)
    {
        // Active record code to get site by id
    }

    public function get_sites_by_user_id($user_id)
    {
        // ...
    }

    // ...

    public function get_site_by_user_id_and_url_string($user_id, $url_string)
    {
        // ...
    }

    // Non active record methods and business logic
    // ...

}

Этот подход хорошо сработал для меня, но мне интересно, есть ли более элегантное решение.Мне просто кажется неправильным, что мне нужно создавать новый метод каждый раз, когда мне нужно искать данные по-новому.Это обычная практика или я упускаю способ реорганизовать это?

Answer 1

Строго следуя вашему запросу, вы можете добавить промежуточный класс между основным классом модели (CI_Model) и вашим классом (Site), что-то вроде

class MyCommonMethodsClass extends CI_Model {
}

и вы расширите его в своих классах (сайте), добавив в него общий код. Это сработало бы и могло бы быть как-то «элегантно». Фактически, в конце вы добавите к нему свои основные действия, адаптированные к сайту.

Теперь, если это «чисто», это другое дело. Опять же, строго говоря, модель делает это. Он заботится об обычных и «продвинутых» добытчиках. И да, они почти всегда имеют одинаковый код на вашем сайте. Проблема в том, что, хотя это выглядит хорошо в вашем коде (меньше кода), вы технически жертвуете абстракцией между вашей бизнес-логикой и БД. Вы модельный пурист или практичный?

Answer 2

Я думаю, что это вопрос мнения, но я думаю, что лучшая практика - это создать какую-то модель Create, Retrieve, Update, Delete (CRUD), которая выполняет многие базовые функции SQL, такие как GetID, UpdateByID, GetById и т. Д. *

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

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

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

Answer 3

Я не думаю, что с созданием «базового» класса моделей что-то не так, чтобы расширить вас на другие модели. Если он твердый и хорошо протестированный, он может облегчить вам жизнь. Какой смысл снова и снова создавать одни и те же функции CRUD?

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

Если вам нужен пример того, как это сделать, посмотрите на вопрос , который я ранее задавал.

Вы можете сделать то же самое с вашими контроллерами .

Answer 4

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

Преимущества этого подхода:

• Вы не повторяете работу (SPOT, DRY)
• Код, который взаимодействует с классами, может быть написан в более общем виде и может обрабатывать любой объект, который наследуется от суперкласса (подстановка)

Answer 5

Обычной практикой является использование различных методов для получения таких данных. Принцип Single Responsibility гласит, что каждый объект должен делать только одну вещь, создавая несколько методов, которые получают очень специфические данные, которые вы создаете, очень понятный и простой в отладке код.