Только что начал исследовать mvc, и я не уверен, что понимаю его. Из того, что я собираю, это похоже на реализацию трехуровневого решения, т. Е. Модель соответствует уровню DAL, Controller to business logic и представлению как Presentation.MVC - это всего лишь трехуровневая модель?
Как я отступаю от базы здесь?
Я не рекомендую рассматривать модель как просто уровень доступа к данным. Это упрощает, и это приводит к тому, что вы добавляете слишком много кода в уровень контроллера. Лучше, если вы поместите больше кода в модель и сделайте упорство базы данных только частью внутреннего кода модели. Мне нравится думать о MVC, как это:
Это, в основном, шаблон Page Controller.
Еще один способ подумать об этом: предположим, вам пришлось переносить ваше веб-приложение на другую платформу, например, приложение из командной строки или приложение для графического интерфейса пользователя. Какие части логики приложения следует использовать повторно? Контроллер и просмотр будут меняться при переносе приложения на другую платформу, потому что реализация обоих входных и выходных данных должна измениться. Код, который не нуждается в изменении, должен быть реализован в вашей модели.
Если вы правильно разделили проблемы, то модель, представление и контроллер будут минимально связаны, и вы можете изменить реализацию одного, не слишком сильно влияя на других. Если вы измените модель, и вы обнаружите, что переписываете большое количество кода в контроллере или в представлении, вы, вероятно, не разделили эти уровни адекватно. И наоборот.
Подробнее о противотанковых устройствах Martin Fowler's Anemic Domain Model или Domain Driven Design Quickly, чтобы получить некоторые другие перспективы.
Также см. Мой blog from 2008, который я написал в ответ на людей, осуждающих шаблон активной записи. У него были хорошие комментарии и дискуссии.
Сорт. Это выглядит следующим образом:
картина наиболее часто используется сегодня:
Database -> DAL -> BLL -> Controller -> View Model -> UI
Где
DAL == Data Access Layer (aka ORM, Object-Relational mapper)
BLL == Business Logic Layer
Обратите внимание, что вы не всегда нужно каждый слой. Например, BLL и View Model могут быть необязательными, если приложение достаточно мало.
Вы должны проверить NerdDinner tutorial. Он описывает все эти концепции в одной ссылке.
Некоторые большие объяснения здесь, если вы новичок в MVC:
Короткая заметка, вы правы, когда вы говорите, что контроллер может (не должно) быть бизнес-слой, и представление представляет собой уровень представления.
Однако модель представляет собой объекты (в зависимости от реализации), которые содержат данные, тогда как слой данных - это слой, который извлекает/управляет данными.
Согласен. Тощие контроллеры и жирные модели облегчают мою жизнь. –