Как правильно разделить класс?

Здравствуйте.

Изучаю основы ООП и MVC на тестовом проекте - каталог организаций.
Есть несколько вопросов по архитектуре, подскажите, пожалуйста.

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

Сейчас все, что связано с организациями находится в одном классе Companies.
Есть контроллер, модель и view.

Контроллер и модель имеют методы как на получение списка всех компаний, так и просмотр и редактирование конкретной компании.

Подозреваю, что это неправильно и нужно создавать отдельные классы и подключать их из модели и контроллера:
Компания
— Категория
— Адрес
— — Время работы
— — Контакты

Правильно?

И еще:
Как быть с отображением списка компаний, в каком классе реализовать получение списка и с какого класса получить, например, список категорий, в которые сходит каждая компания из списка?
  • Вопрос задан
  • 207 просмотров
Пригласить эксперта
Ответы на вопрос 3
@eternalfire
Хорошей практикой служит написание прослойки или промежуточной модели между контроллером и моделью, которая и содержит в себе всю бизнес-логику
Её ещё называют сервисом
То есть контроллер управляет сервисом, который в свою очередь и дёргает модели
Ответ написан
ThunderCat
@ThunderCat Куратор тега PHP
{PHP, MySql, HTML, JS, CSS} developer
Подходов масса, и все имеют свои недостатки и преимущества. Я обычно разбиваю на вменяемые "физические" сущности: адрес, телефон, компания, почта... в таком случае объединения в коллекции принадлежностей могут быстро сменять метод отношений от один ко многим к многие ко многим простым добавлением таблицы связей. В логике тоже будет всего 2-3 мелкие правки. Хранить все в одной таблице/сущности наиболее худший вариант.
Ответ написан
Комментировать
@red-barbarian
Идея MVC, MVP, MVVM и тд в том , что бы отделить бизнес модель от ui. Т.е. безнес модель не должно волновать какой там будет контролер и проч.
поэтому рассуждая о модели и оглядываясь на контролера сигнал, что что-то не в порядке в нашей архитектуре.
Далее, для уменьшения запутанности в будущем ))) лучше бизнеслогику описывать в сущностях предметной области. Например
Компания
Категория
Адрес
и проч
Реализация должны быть скрыты.
Итого выбор из двух представленных моделей сводится к тому какая модель ближе к предметной области:
Категория.выдатьСписокОрганизаций
Организация.выдатьСписокАдресов
или
Компания.выдатьСписокКатегорий
Компания.выдатьСписокАдресов
По сути отличие только в первой строке. И отличие в том что чаще используется : зависимость категорий от организаций или наоборот. Что чаще, то должно реализовываться проще. в случае если нужны две зависимости, в модели должны быть реализованы два случая.

Замечу, что реализация хранения объектов бизнеслогики должно быть скрыто за интерфейсом типа репозитория. Он будет выдавать готовые сущности независимо от базы данных или получения данных.
Вот типа так. Хотя срезать углы никто не запрещает уменьшая количество слоем в архитектуре или интерфейсов. ))) Просто нужно понимать, что делая так мы повышаем количество связей между частями системы, но уменьшаем количество написанного кода. Баланс зависит от случая.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы