Прошу прощения, что так и не ответил на ваш вопрос. Сейчас случайно увидел :) Если еще интересно, то разделение вью-слоя и логики по сути сервис-ориентированная архитектура. В принципе, можете почитать про SOA, но если вкратце, то преимущества такие: надежное разделение кодовой базы, разделение ответственности, упрощение мониторинга и оптимизации отдельных частей проекта и тому подобное. Хорошо работает для больших комманд.
Grails, Play, Django и тому подобные — это так называемые rapid web appication frameworks, для крупных проектов не годятся, так как построены на некоторых упрощениях (собственно благодаря чему и достигается rapid), что в сложных случаях выходит боком.
Возможно что-то вроде Pyramid было бы неплохо, однако было еще требование асинхронности, так что было разработано свое.
Довольно давно уже не использую спринг в плотную, так что могу ошибаться. Инстанциирование бинов настраивается конечно как через аннотацию @Component (инъекция через аннотацию @Autowired), так и через java-конфиг. Единственное, на сколько я понял, не все возможно настроить через java-конфиг, кое-что включается через xml-ник. То есть приложение выглядит как небольшой xml-ник с настройками, все остальное аннотациями.
Кстати, со спрингом перестал работать, так как в нашей компании отказались от java-фреймворков для построения web-представления и перешли на Python-решение. На java же пишутся REST сервисы, отдающие xml.
Что касается корпоративных решений, то там видимо рулит JSF и компания. Однако довольно тяжелая это технология. Для сайтов любой сложности, при этом с минимальным оверхедом, лучше всего Spring MVC, так как Spring это вообще самодостаточная технология, кроме того достаточно быстрая. Еще часто слышу про всякого рода порталы, можете посмотреть (JBoss Portal, Liferay)
По-человечски, это state-base тестирование: martinfowler.com/articles/mocksArentStubs.html#ClassicalAndMockistTesting. Вообще советую прочитать весь пост Фаулера. Изоляция ради изоляции не верный путь. Да и потом многие используют моки потому, что модно. Если увлекаться моками, то тест начинает а) ломаться, когда код фактически работает (моки проверяют не фактический результат, а ерунду вроде порядка вызовов методов). Когда не получается сделать state-based, нужно попытаться отрефакторить или внедрить fake-объекты. Ну и если ничего не помогло, то моки.
Вот пример, где моки уместны: мы пишем менеджер транзакций, который выполняет код в транзакции, если происходит ошибка, то после rollback происходит еще одна попытка выполнить код и так заданное количество раз. В этом случае мы с помощью моченного целевого кода как раз сможем посчитать сколько раз он был вызван менеджером.
Хм, почитал на вики, действительно, вы правы. Несмотря на странное название сетевая модель похожа на иерархическую. Только у каждой записи может быть более одного предка.
Я правильно понимаю, что ваше решение в чем-то аналог APR-вского Memory Pool? Насколько я понимаю он имеет очевидный недостаток — нам нужно знать, что вот такой-то граф объектов более не нужен и его можно удалить целиком. Такая схема отлично подходит для сетевых серверов — мы можем чанк-аллокатором выделять всю память для обработки одного конкретного запроса, потом удалить весь чанк целиком. Это и быстро и безопасно.