Codeigniter, когда создавать новые контроллеры / модели - PullRequest
0 голосов
/ 06 мая 2018

Я смотрел много руководств / уроков по YouTube, но они касаются только части кода.

Всякий раз, когда я запускаю проект, я всегда начинаю с простого контроллера, называемого main. и 2 модели.

Например: если бы я начал проект интернет-магазина. Тогда моими моделями будут «product_model» и «user_model». Все функции базы данных для пользователей, я всегда помещаю их в 'user_model' и все функции базы данных для продуктов, я всегда помещаю их в 'product_model'.

user_model:

public function register(){

}

public function login(){

}

//more functions for user

Код продукта:

public function create_product(){

}

public function review_product(){

}

//more functions for product

Моя проблема в том, что я легко путаюсь с моим проектом и / или недоволен тем, насколько он неорганизован. особенно когда я нахожусь на полпути в проект и накапливаю сотни строк кода.

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

Итак, я хочу попросить опытных программистов дать мне основное руководство, когда создавать новую модель и новый контроллер?

Как сгруппировать функции и превратить их в отдельную модель?

Я делаю новую модель для каждой таблицы? и все функции базы данных в этой таблице я просто записать в новой модели, созданной для этой таблицы?

Или

Сгруппирую ли я функции базы данных в зависимости от того, что они делают? Например: покупка продукта включает в себя множество отдельных функций базы данных. так что сохраните их все в purchase_model?

1 Ответ

0 голосов
/ 06 мая 2018

Ответ на все эти вопросы: зависит . Лично я считаю, что именно гибкость делает программирование таким интересным.

Как правило, я стараюсь, чтобы все мои классы содержали менее 500-700 строк кода, а функции - менее 20 строк кода. Если мой класс становится больше, я обычно начинаю новый. С учетом вышесказанного, контроллеры, с которыми я в порядке, больше, так как проверка формы и логика ответов могут занимать довольно много строк.

Итак, давайте рассмотрим пример: система аутентификации пользователя

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

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

В целом

Вы должны решить:

  1. Сколько кода слишком много для контроллера / модели?
  2. (с указанным выше) Ожидается ли рост моего кода? Если это так, то я должен учитывать, сколько при определении (1).
  3. Как мне группировать функции? Для этого имейте в виду разделение интересов, например, функции аутентификации не должны группироваться с функциями резервного копирования базы данных.
  4. Я слишком много делаю в конкретной функции / модели? Если да, то как мне отделить эти элементы, чтобы я соответствовал принципам СУХОЙ (скорее всего, какой-то код можно использовать в другом месте, хотя его функциональные возможности по своей сути различны).
  5. (с выше) Если этот код действительно так полезен в другом месте, я должен превратить его в библиотеку / помощник?

(и есть множество других вещей, которые нужно учитывать).

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

Дополнительное примечание: вы можете исследовать подход ORM к моделям (Laravel и множество других фреймворков используют его), но CI использует более «любой» подход практически ко всему. Если принуждение работать определенным образом заставляет вас чувствовать себя в большей безопасности, вы можете изучить другие «более продвинутые» и «более новые» фреймворки.

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