Я предостерегаю не рассматривать Модель как просто слой доступа к данным. Это упрощает и приводит к тому, что вы помещаете слишком много кода в слой контроллера. Лучше, если вы добавите больше этого кода в модель и сделаете постоянное хранение базы данных только частью внутреннего кода модели. Мне нравится думать о MVC так:
- Контроллер: обрабатывать ввод, определять, какую модель и какой вид создать для экземпляра
- Просмотр: представление данных приложения
- Модель: вся другая логика для приложения, включая, но не ограничиваясь, DAL
Это в основном шаблон Page Controller .
Еще один способ думать об этом заключается в следующем: предположим, что вам пришлось перенести ваше веб-приложение на другую платформу, такую как приложение командной строки или приложение с графическим интерфейсом для настольного компьютера. Какие части логики приложения следует использовать повторно? Контроллер и представление будут меняться при переносе приложения на другую платформу, потому что реализация ввода и вывода должна будет измениться. Код, который не нужно изменять, должен быть реализован в вашей модели.
Если вы правильно сделали разделение задач, то модель, представление и контроллер были бы минимально связаны, и вы могли бы изменить реализацию одной из них, не слишком сильно влияя на другие. Если вы измените модель и обнаружите, что переписываете большой объем кода в контроллере или представлении, вы, вероятно, не разделяли эти слои должным образом. И наоборот.
Прочтите о Анемичной доменной модели Мартина Фаулера antipattern или Управляемый доменом дизайн Быстро , чтобы получить другие перспективы.
Также посмотрите мой блог за 2008 , который я написал в ответ на людей, осуждающих шаблон Active Record. Он получил несколько хороших комментариев и обсуждения.