Только начал исследовать mvc и пока не уверен, что понимаю. Насколько я понимаю, это похоже на реализацию трехуровневого решения, т.е. Модель соответствует DAL, Контроллер - уровню бизнес-логики и Представлению как уровню представления.
Я здесь далеко от базы?
Я не рекомендую рассматривать Модель как просто уровень доступа к данным. Это чрезмерное упрощение и приводит к тому, что вы помещаете слишком много кода на уровень контроллера. Лучше, если вы поместите больше этого кода в Модель и сделаете постоянство базы данных только частью внутреннего кода Модели. Мне нравится думать о MVC так:
По сути, это шаблон Контроллер страницы.
Еще один способ подумать об этом: предположим, вам нужно было перенести свое веб-приложение на другую платформу, такую как приложение командной строки или настольное приложение с графическим интерфейсом. Какие части логики приложения следует использовать повторно? Контроллер и представление будут меняться по мере того, как вы переносите приложение на другую платформу, потому что потребуется изменить реализацию как ввода, так и вывода. Код, который не нужно изменять, должен быть реализован в вашей модели.
Если вы правильно сделали разделение задач, тогда модель, представление и контроллер будут минимально связаны, и вы сможете изменить реализацию одного, не слишком сильно влияя на другие. Если вы меняете Модель и обнаруживаете, что переписываете много кода в Контроллере или Представлении, вы, вероятно, не разделяете эти слои должным образом. И наоборот.
Прочтите об антипаттерне Мартина Фаулера Модель анемического домена или Домен-ориентированный дизайн быстро, чтобы получить некоторые другие точки зрения.
Также см. Мой блог 2008 года, который я написал в ответ людям, осуждающим паттерн Active Record. Он получил несколько хороших комментариев и обсуждений.
Вроде, как бы, что-то вроде. Выглядит это так:
Чаще всего сегодня используется следующий паттерн:
Database -> DAL -> BLL -> Controller -> View Model -> UI
Где
DAL == Data Access Layer (aka ORM, Object-Relational mapper)
BLL == Business Logic Layer
Учтите, что вам не всегда нужен каждый слой. Например, BLL и View Model могут быть необязательными, если приложение достаточно маленькое.
Вам следует ознакомиться с учебным пособием по NerdDinner. В нем все эти концепции описаны в одном справочнике. .
Вот несколько замечательных объяснений, если вы новичок в MVC:
Кто-нибудь, кроме меня, просто НЕ получает ASP.NET MVC?
Короткое замечание: вы правы, когда говорите, что Контроллер может (не обязательно) быть бизнес-уровнем, а представление - уровнем представления.
Однако модель - это объекты (в зависимости от реализации), которые содержат данные, тогда как уровень данных - это уровень, который извлекает / манипулирует данными.
