Как приготовить Java SE + MVC + SWING + DependencyInjection/IoC?

0) Из всех языков, что я видел, java наиболее близка к моему пониманию "канона ООП"

1) По обоим ссылкам как раз имеется привязка модели к представлению, мне нужно чтобы они были связаны ровно никак и всё бы происходило через контроллер, и уж тем более недопустимо делать для всех моделей суперкласс (моя идея как раз модели, которые могут быть использованы и для web, и для толстых клиентов). Представление тоже должно быть поумолчанию независимым, чтобы была возможность, например, отправить логику отображения через JNI в Qt.
2) DI мне нужен ибо привык и удобно (тесты писать + вероятнее всего значительно проще будет реализовать Plugin используя DI, нежели через тонны абстрактных фабрик завязаных на сомнительные реестры). За ссылку спасибо.

На самом деле я хочу сотворить нечто наподобие Spring (Java)/Symfony2 (PHP), только для Swing, для меня это стало каноном реализации начальной архитектуры.

Кстати не посоветуете пару ссылок на исходники чего-нибудь большого с плагинами для Swing? (иногда проще понять по хорошим сорцам)

Кирилл Саксин: Ох, простыня щас будет...
0) В яве много минусов в плане ООП:
a) отсутствие параметризированных типов в runtime из-за type erasure генериков. Получить тип можно либо через костыли, либо передавая в каждый метод, зависящий от типа, этот тип напрямую, что добавляет кучу лишнего кода.
b) Только ad-hoc полиформизм, а было бы круто, если бы он был параметрический
c) Диспетчеризация только по одному типу (метод принадлежит объекту, из которого он вызван). В объектной системе лиспа CLOS есть мультиметоды. Их можно параметризовать как одним классом (тогда будет как в яве/питоне/других языках), так и несколькими (тогда будет множественная диспетчеризация). Почитай про него, полезно хотя бы для общего понимания, какое ООП вообще бывает.
d) Классы - не объекты. Это очень печалит. В том же питоне любой класс - это полноценный объект, его можно хранить в переменной, и т.д. В java есть только костыли вида Class.
e) Как следствие - отсутствие метаобъектов
f) Отсутствие множественного наследования (хотя бы в урезанном виде: mixins, traits, delegates). e и f частично решается в scala и groovy.
Вообще, любой прототипный язык (js, lua, io) намного ближе к классической парадигме. ООП в стиле java/c++/c# просто более популярное (потому что более простое для понимания).

1) Нет, ты неправильно понимаешь MVC.
Model - это данные + бизнес-логика. Модель ничего не знает о том, как отображать их. Модель ничего не знает, кто, как и когда подписался на рассылку её оповещений. Однако, модель должна оповещать слушателей.
View - это то, как отображать данные. Без модели он бесполезен - нечего отображать. Соответственно, view должен быть связан с моделью напрямую (либо через посредника, но это не Controller).
Controller - это тонкая прослойка, связывающая пользователя с программой. Контроллер не должен связывать View и Model.

Model + View - это обычно паттерн Observer: модель (Observable) хранит в списке всех заинтересованных слушателей. Она имеет методы для добавления/удаления новых слушателей, ну и конечно - оповещение. Модели не важно, есть ли в списке ноль, один или сто слушателей. При изменении данных в модели она просто в цикле передаёт сообщение всем слушателям. View - это Observer. При поступившем событии от модели View обрабатывает полученное сообщение и что-то делает с данными.
View + Controller - это паттерн Strategy. При каком-то событии контроллер выбирает конкретную стратегию поведения, берёт данные из представления и выполняет выбранную стратегию в модели.

При этом, нет никакого противоречия в независимости компонент. Разрабатывать модель можно без знания о V и С. Модель лишь предоставляет интерфейс для обработки данных. При этом, не изменяя модель ты сможешь прикручивать к ней разные представления (которые могут быть написаны даже на разных языках).
View должен знать о модели, но не о контроллере. View должен уметь подписываться на события изменения данных из модели и обрабатывать приходящие изменения. При этом, не изменяя представление, ты можешь задавать ему разные стратегии поведения при действиях пользователя, достаточно просто изменить соответствующий контроллер. Опять же, контроллер может быть на другом языке, ничего не мешает это реализовать.

Вот пример: модель NumbersList хранит список чисел. Есть 3 view: одно отображает числа в виде круговой диаграммы, второе в виде столбчатой диаграммы, третье - в виде списка полей ввода. При старте программы все три подписываются на события модели NumbersList. В любой момент ты можешь отсоединить/присоединить представления по своему жеданию, естественно ничего не меняя в модели. При нажатии кнопки "отправить" контроллер соберёт числа из текстовых полей и отправит их в модель для обновления. Когда данные в модели изменяются, она в цикле высылает всем представлениям обновлённые данные. Все 3 view изменят свой внешний вид на соответствующий. Теперь, не трогая реализацию View, можно добавить контроллер, который при нажатии на столбец диаграммы передаст в модель значение соответствующего числа, но увеличенного на единицу. Можно повесить ещё один контроллер, который при нажатии на правую кнопку мыши будет высылать модели уменьшенное значение.

Вот это классическая реализация MVC, всё остальное - это не MVC.

2) Примеры, зачем нужно использовать внедрение зависимостей в JavaEE:
a) Выбор реализации EntityManager. Ты настроил в xml свои источники данных. В сервисе ты инъектишь через аннотацию эту зависимость. Сервер приложений сам парсит xml-файлы, выбирает нужный persistence unit (их может быть много, по-сути один юнит на одну БД в СУБД), смотрит, какие реализации JPA API он может использовать (а реализация может быть как встроенной в сервер, так и быть в виде jar-ки, которая входит в проект). При этом, сервер сам сможет следить за транкзакциями и обеспечивать безопасность. В JavaSE это не нужно, так как ты при запуске приложения сам создаёшь соединение (только из приложения, больше неоткуда) и подрубаешь нужный EntityManager в нужный бин через фабрику. Внедрение зависимостей только усложнит дело, а не упростит.
b) Управление временем жизни бина. Хороший пример - JSF. Можно сделать бин живущим, только для одного запроса (@RequestScope). Тогда для каждого запроса (вне зависимости от пользователя) этот бин будет жить только от поступления request до отдачи response. Можно сделать бин для сессии - @SessionScope. Когда заходит пользователь, для которого сессия не найдена, создаётся этот бин. Все данные он хранит до тех пор, пока сессия не протухнет. Таким образом, можно, например, изменять данные на странице без её перезагрузки (например как в админке GlassFish). Можно сделать бин @ApplicationScope. Он будет доступен всем вне зависимости от сессии и других сетевых параметров пока живёт само приложение. В свинге просто не предусмотрен многопользовательский режим: единственный пользователь - это тот, который запустил это приложение. И время жизни там только от запуска приложения до его завершения. Тут просто нет смысла управлять бинами.
c) Обеспечение транкзакций, передачи сообщений и безопасности. Для бинов, аннотированных через @EJB, сервер предоставляет гарантию транкзакций и безопасности (если сама реализация бина аннотированна всякими @Transactional, @ManagedBean и т.д.) Плюс, бин можно сделать удалённым и управлять им через JMS. Доставку собщений так же гарантирует сервер. В свинг-приожениях это просто не нужно.

В общем, ты только запутаешь свою систему с DI. Ведь тебе надо будет самому реализовывать многие вещи. Выбор нужной реализации конечно будет выполнять DI framework (если подходящая реализация только одна), однако при созданий множества реализаций одного интерфейса нужно уже вручную указывать, какую реализацию использовать. Серверы приложений - это огромное количество человекочасов, в одиночку сложно будет реализовать всё это.
Ну и самая простая причина не использовать DI состоит в том, что свинг-прилолжения простые: они не многопользовательские, они не предполагают управление временем жизни и контекстом приложения (ведь приложение запускается напрямую, а не в контейнере), они не предполагают выбора из множества реализаций API, всё идёт в compile-scope.
Самое простое и очевидное - просто использовать фабрики, а в каждом бине хранить его настройки в виде констант. Либо использовать аннотации при создании объектов/объявления классов, но без DI. Либо хранить настройки в файлах конфигов, если хочется гибкости. Этого хватит с головой.

А вот приложений на свинге не могу порекомендовать, поищи на гитхабах.

bromzh:
0) Спасибо, буду просвещаться)
1) Видимо мой отбитый вебом мозг считал что MVC ближе к MVP, стыд мне позор...
2) Это я как-раз знаю, но у меня есть 2 идеи, которые требуют полноценной системы плагинов, где каждый плагин по-хорошему должен иметь доступ ко всем сервисам системы (опять моя зацикленность на SOA), и честно говоря я не представляю как это красиво (без god-object в котором будет всё и вся и полтораста методов на получение сервисов) реализовать без внедрения зависимостей, есть идеи?