Хорошо, в основном: separation of concerns на уровне использования, а не на физическом уровне.
Цитирование PoEAA on MVC
MVC разделяет взаимодействие пользовательского интерфейса в трех различных ролей.
С MVC вы отделяете презентацию (V, C) от логики домена (M), а также отделяете поведение пользовательского интерфейса (C) от дисплея пользовательского интерфейса (V). Это гораздо более удобно, чем смешивать все три проблемы в одном, а также способствует повторному использованию и тестированию. Это позволяет вам лучше решать сложность.
Это ничего не касается только веб-приложений. Он подходит для любых приложений с логикой домена и пользовательским интерфейсом. С учетом сказанного, я бы не сказал, что MVC - это наиболее подходящий шаблон для веб-приложения. Если все, что вы хотите сделать, это положить, скажем, контактную форму в Интернете, тогда будет достаточно сценария «все в одну страницу». Если у вас есть только куча статических страниц, MVC тоже излишний. Так что, как и с любыми шаблонами, это зависит от проблемы, которую вы хотите решить.
Что касается n-уровня, то «классический» MVC не предвидел, что он используется в Интернете. При представлении пользовательского интерфейса, происходящего в браузере и контроллере на удаленном сервере, MVC в Интернете всегда является также многоуровневой архитектурой, следовательно, разница между usecase и физическим в начале. MVC просто не интересуется, где это происходит.
Также см:
Rasmus имеет хороший блог о MVC в веб-разработке. http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC-framework.html – vsr
Почему бы не n-уровень * и * MVC? – magnus