Поэтому если подходить к этой проблеме системно, то нельзя отдавать ее на откуп разработчику прикладного функционала в ежедневной работе. А нужно делать удобный фреймворк, который применяется всегда при обработке входных данных. И да, в это придется вкладываться дополнительно, потому что за тебя это не сделал никто ни в Spring, ни в ASP.NET. Это - цена отказа (еще один кусок цены) от зрелых технологий на middle tier. Скорее всего, никто там итого не оценивал, сколько в плюс, сколько в минус, сколько - в риски. Но в принципе - сделать-то можно нормально (нормально будет технически, но не с т.з. поиска кадров, конечно).

Мне кажется, это хорошее упражнение - описать (придумать) такой контекст, где такое решение на сегодняшний день было бы реально и очевидно хорошим.

Ага. Теоретически. Исключительно из любви к науке.

Зачем? Заняться нечем?)

Как любое упражнение - для тренировки :) Здесь - мышления и воображения.

Лично мне хватает тренировки на реальных задачах. Времени спать не хватает, а тренировки хватает)

Про фреймворки уже тоже было. И не раз. Все кто пытался сделать универсальный супер-пупер фреймворк пришли к одной простой мысли - это не никому в итоге не нужно.
Причины банальны - жизнь гораздо разнообразнее и интереснее чем любые наши самые фантастические фантазии. А уж бизнес - так это вообще патентованные фантазеры :)
И как это ни странно выживают только те, кто делает что-то полезное  (в смысле оплаты заказчиком)  :) Даже если результат кажется кривым-косым-плохо покрашенным, но работает - он гораздо ценнее, чем сферическое решение в вакууме. Я уж не говорю о том, что каждые 5 лет у вас на проекте будет меняться команда и будут приходить снова парни готовые все переписать за ночь, но как правило плохо понимающие первые 1,5-2 года что ж это они на самом то деле делают (ну да, от масштабов зависит). И в итоге единственное, что в вашем решении будет наиболее ценно - простота и внятное разделение ответственности. И чем меньше слоев - тем лучше. И чем меньше задач решает слой - тем лучше. В общем - идеальная система это та, в которой нет ни строчки кода но проблема решена :)

:) Идеальную программу можно написать на Хаскеле, но в ней не должно быть ввода и вывода.

Вообще не понимаю, как мысль перескочила на "универсальный супер-пупер фреймворк". Я говорил про фреймворк в конкретном приложении.

Да это и не для студентов сложно. Впрочем, студентам это и не нужно.

Да, это точно (про сложность). Но чему тогда студентов учить в тематике паттернов?

Выделять их самостоятельно, т.е. учить формулировать "я вижу то-то, и смотрю так-то, значит, можно сказать, что ....".

А зачем их этому учить? Нужно учить здравому смыслу и возможности смотреть с разных viewpoint. А архпаттерны - это уже в курсе для техлидов и выше

Я боюсь, что для студента знание арх.паттернов скорее вредно )

Это, конечно, реально непростой вопрос - чему учить, а чему - не стоит. И, конечно, он очень сильно зависит от контекста - кто будет учить, как, кого хотим получить на выходе, чего хочет сам студент, учить в бакалавриате или магистратуре, и т.п.

Но я бы поставил вопрос так (может, слегка теоретически). Можно ли учить в вузе (скажем, в магистратуре по IT) так, что выпускник СМОЖЕТ выполнять архитектурную работу с приемлемым качеством на простых проектах. Что он такую работу (а может и разработческую работу) выполнит в среднем лучше, чем если его НЕ учить чему-то про архитектуру вообще и паттерны в частности? И мне хочется сказать, что "да, можно, к этому надо стремиться". В противном случае - ну, мы просто опускаем руки, и говорим "все через опыт на работе", а это признание поражения (с позиции образованца), и вообще непонятно на каком основании.

Кажется, тот же вопрос стоит про обучение управлению, и, как мне кажется, неспроста он такой же полемичный.

Я сталкивался с тем что статьи/книги/курсы рассказывают что есть вот-такие вот паттерны, но не рассказывают их границы применимости: где стоит использовать, а где нет

Где стоит ещё как-то можно понять, потому что при описании паттернов описывается контекст и решаемая задача.

Конечно, преподавать ПЛОХО, и делать разные глупости в преподавании - возможно (и для сырого знания так и будет долго). Но повод ли это говорить "давайте вообще не будем учить, и не будем думать как надо учить, потому что все равно научат только плохому"?

(Я понимаю, что из позиции индустрии в отношении пост-советских вузов сейчас такое отношение вполне естественно)