fixxerЯ один ни в одном посте Petro123 так и не понял, что же он конкретно хотел сказать?
Он считает что Spring XML, как и DI вообще это оверхед на целом ряде проектов. Как он пришел к таким выводам, я не очень понял.

Йуный джавистЪДля того чтобы перейти на работу с двумя базами, надо будет в каждом месте, где используется база, указать, где используется первая база, а где вторая. Для этого в любом случае придется перелопатить весь проект. В примере Petro надо будет просто заменить HibernateUtil.getSessionFactory().openSession() на HibernateUtil.getAnotherSessionFactory().openSession() - это минимальная правка, короче никак нельзя сделать.

А, если мне нужно один и тот же метод в разных базах, в зависимости от контекста? Это всё нормально настраивается при DI, но в примере Petro123 - опять перелопачивать все DAO. Я лишь показываю как в конкретное данном примере изменения, внешние для слоя DAO начинают менять код самих DAO. Это очень показательный пример, который показывает как статические синглтоны убивают полиморфизм, который можно сохранить при использовании DI.
Мы же не говорим конкретно о работе DAO или Hibernate. Мы сравниваем - статический синглтон HibernateUtil.getSessionFactory() с DI. Очевидно что статический синглтон не обладает полиморфизмом и является глобальной переменной. Поэтому код с его использованием вызывает большую волну изменений. Чем при использовании DI, где зависимости подменить проще и за счет этого волна изменений гасится быстрее.


Йуный джавистЪИспользуйте AspectJ если вам сложно написать такой код. AspectJ не требует никаких спрингов и прочих DI.
Я не спрашивал как именно сделать лучше. Я лишь указал на недостаток кода, который был приведен как контрпример DI. Причем не самый удачный.


Йуный джавистЪВообще в Java тупой копипаст неизбежен.

Тут есть нюансы. Во-первых вы правы в том что в некоторых случаях копипаст в Java проще. Потому что если применять функциональные подходы на генериках и анонимных классах, то результат приведет к коду в два раза больше и раз в пять сложнее для чтения. Хотя функциональный код вообще сложнее для чтения и фильтры это классический пример.

Во-вторых не так давно я осознал что копипаст местами не такое уж и зло. Например в GUI формах. Которые часто подвержены изменениям, переиспользование кода часто усложняет дальнейшие более тонкие и индивидуальные изменения.

Ну, и в-третих вы правы, это все же к DI имеет не самое прямое отношение. Можно тему копипаста дальше не развивать.

Petro123я не понял твоей хотелке "поиметь" сразу 2 БД.
Ты в рантайме ПОЛЬЗОВАТЕЛЕМ хочешь менять. Или конфигом аппСервера или как?
Речь не о 2х БД пользователях и пр. Речь о сравнении статических синглтонов (Singleton.getInstance()) и не статических DI.
Есть статический метод getSessionFactory(). Он не обладает полиморфизмом. Соответсвенно проблема - не может быть двух SessionFactory без значительных изменений в коде.

Йуный джавистЪМожно ранее в треде устанавливать ThreadLocal переменную, которую getSessionFactory() потом будет читать. Тогда getSessionFactory() становится полиморфным.
В Common Lisp, например, System.out является полиморфным из коробки посредством использования похожего механизма (dynamic scoping).
ThreadLocal подходит только многопоточного сервера. И таким образом вы утверждаете что ThreadLocal лучше чем полноценный полиморфизм?

Йуный джавистЪПочему?
Потому что GUI, например, однопоточный.

Petro123может я ничего не понял. Но на кой мне Две фабрики?

Например, для работы с разными БД.

Petro123Это же синглетон - статика?

Эта статика у тебя прописана в каждом DAO - глобальная не полиморфная зависимость.

Petro123Все конфиги-варианты через XML хибера (до загрузки).
?

Йуный джавистЪЕсли хочешь - приводи задачу с одной базой и изменение в требованиях, которое требует вторую базу. Я напишу сначала код, который выполняет исходную задачу, потом отрефакторю под новые требования.
Ещё раз. Базы тут не причем. Проблема двух баз это не самоцель. Это следствие использование статического синглтона.
Лучше ты объясни почему статический синглтон лучше чем DI?