Очень нубский попрос. Почитал вики, различные разжевывания концепции, часто видел реальные примеры, но кое-что все-таки не дает покоя. Хочется раз и навсегда прояснить тонкости. По какому принципу отделяются функции в контроллере от функций в модели? Правильно ли я понимаю, что в контроллере должны быть методы, которые инициируются каким-либо событием, а в модели - все остальные (т.е., грубо говоря, если нам не нужно больше одного метода на какое-то событие, напр. открытие новой страницы, можно написать этот метод в контроллере и это будет правильно)? Если же логика сложна и одним небольшим методом не обойтись, то можно: - использовать метод в контроллере как обертку для вызова метода модели - вызвать вспомогательные методы в модели, работающие с данными ? P.S. Методы для работы с СУБД - тут я бы выносил их в отдельную библиотечку. Просто потому, что хранить их в модели неправильно. И получается, что в моем представлении модель в любом случае по объему получается меньше контроллера, хотя теоретически должно быть наоборот.
Ответ
Правильно ли я понимаю, что в контроллере должны быть методы, которые инициируются каким-либо событием В общем - да а в модели - все остальные (методы) ... Методы для работы с СУБД - тут я бы выносил их в отдельную библиотечку. Не все. У контроллера, модели и представления есть свои разграниченные области - связка запросов, модели и представления; работа с данными; вывод. Все остальное лежит на внешних библиотеках, и MVC слабо волнует, что в этих библиотеках происходит, пока они выполняют свои функции. Модель не включает в себя БД, БД - это провайдер данных, модель могла бы брать эти данные и из другого сервиса, и из json-файлов, в этом случае провайдерами были бы сетевая передача и десериализация данных или функции файловой системы и json-парсер. В большинстве случаев этот провайдер тесно интегрирован с моделью (потому что предполагается, что работа всегда будет с БД, и сложно сильно абстрагироваться от SQL-запросов так, чтобы запрос к тому же json-файлу и БД был одинаковым), но в теории можно создать интерфейс этого провайдера, и вынести БД из модели полностью. т.е., грубо говоря, если нам не нужно больше одного метода на какое-то событие, напр. открытие новой страницы, можно написать этот метод в контроллере и это будет правильно Вообще - да. Иногда получается так, что контроллер приходится делить для повышения читаемости (например, страница должна отдаваться в произвольном формате, и ajax-запросы отдаются на один контроллер, а обычные - на другой), но обычно подобное - это красный флаг с надписью "что-то явно делается не так". Но, конечно, в контроллер действия попадают не просто потому что там нужно "не больше одного метода", а потому что это событие - это запрос, и его надо обработать. Если же логика сложна и одним небольшим методом не обойтись, то можно: - использовать метод в контроллере как обертку для вызова метода модели - вызвать вспомогательные методы в модели, работающие с данными ? В целом все верно, просто, опять же, деление должно происходить не по количеству вызовов, а по логике приложения. Какие-то вещи, например, проверку прав доступа, надо производить в контроллере, просто это стоит вынести в базовый класс. А вообще - да, чем тоньше контроллер, тем легче работается и больше когда повторно используется. И часто бывают случаи, когда контроллер состоит из пары строчек и действительно является не более, чем оберткой. Очень нубский попрос. Почитал вики, различные разжевывания концепции, часто видел реальные примеры, но кое-что все-таки не дает покоя. Хочется раз и навсегда прояснить тонкости. Это нормально, у меня тоже понимание довольно долго приходило, а "Где же должна лежать такая-то функция?" - стандартная тема для дев-срача. Тут нет однозначного твердого стандарта, и критерии оценки верности решений могут быть косвенными - если все легко и удобно расширяется, встраивается, рефакторится и очевидно отсутствие костылей, то все в порядке. Но если в контроллере почему-то форматируются свойства модели, то тут вопросов по поводу корректности быть не должно.
Комментариев нет:
Отправить комментарий