Мне кажется вы не там ищете гибкость. На конкретную задачу используется своя вьюха, у нее смысл такой: отобразить данные по-своему. А в вашем примере, достаточно добавить одно условие к конкретной странице и она уже не такая гибкая, допустим на странице пользователя отображать посты без количества комментариев, а на странице постов с ними.
В любом случае, как я уже выше писал, любой подход не панацея, нужно во-первых использовать мозг и только потом шаблоны.
Насчет первого примера ошибаетесь. Автор как раз все правильно описал. Задача получения постов просто уходит в модель один раз и вызывается когда нужно, а не решается каждый раз в контроллере. Представление же просто обращается к постам пользователя $user->posts, причем даже более логично чем просто $posts.
Насчет правильной архитектуры вопрос, на мой взгляд, субъективный для каждой задачи. Здесь мне кажется не нужно закапываться в идеологию, когда можно сделать проще для маленькой задачи или проекта.
>> все они рано или поздно закатятся в лузы
Не факт, если предположить что один оставшийся шар двигается перпендикулярно бортам о которые ударяется, то он никогда не закатится в лузу.
Кстати да, аэропорт наверное самое стрессовое место(не знаю как в метро, ни разу не был). Много людей расстаются, кто-то нервничает в ожидании приезда, кто-то очень не любит ожидание + очередь, в конце концов просто могли нахамить.
Тестирование обычно проводят практически, а не теоретически. Хорошо конечно, что программа знает много всяких лиц, только мы живем в реальном мире. Террористом вполне может оказаться псих (т.е. действительно психически не здоровый человек) и на лице у него будет безмятежность. Да и вообще программу(в общем смысле этого слова) надо делать не так, как вы думаете она будет работать, а всегда учитывать самые невероятные ситуации.
Не одного. Случаев забивательства со стороны Яндекса предостаточно. 4 год уже обновляют карту Оренбурга, про маршруты вообще молчу, по мнению яндекса он — один, где бы не были начальная и конечная точки. И таких случаев масса.
В любом случае, как я уже выше писал, любой подход не панацея, нужно во-первых использовать мозг и только потом шаблоны.
Насчет правильной архитектуры вопрос, на мой взгляд, субъективный для каждой задачи. Здесь мне кажется не нужно закапываться в идеологию, когда можно сделать проще для маленькой задачи или проекта.
Не факт, если предположить что один оставшийся шар двигается перпендикулярно бортам о которые ударяется, то он никогда не закатится в лузу.
Камень в сторону IE?