Может кто-нибудь привести пример хорошо спроектированого (удобного в использовании) DAO интерфейса?
Чтобы была предусмотрена возможность делать разнородные выборки, груповые update'ы и delete'ы по какому-то признаку или набору признаков и т.п. И все это как-то абстрактно оформлено...
Поправьте плз, если хочу странного...

this / это смотрел ?

Это сообщение отредактировал(а) v2v - 21.5.2008, 00:00

v2v
А вот что там вместо точечек будет?

Maksym, List<Object> 
параметры зависят от твоих объектов и поставленной задачи, универсальный я думаю будет сложновато придумать ...

Это сообщение отредактировал(а) v2v - 21.5.2008, 00:07

Паттерны это все здорово. А какая-нибудь реализация, грамотная...в качестве примера..?

Maksym,  а как же родненький сан  ?   
http://java.sun.com/blueprints/corej2eepat...cessObject.html

Молодец, Maksym, интересный вопрос поднял.

Если говорить о готовых разработках, то мне таковые не попадались. Но некоторыми мыслями по теме поделиться могу, поскольку многие вещи довольно много обдумывал и кое-что реализовал в своих проектах.

Сначала о том, что буквально только что пришло в голову: а ведь можно сделать универсальный параметризованый ДАО! Давайте попробуем плясать вот от такого:



Тогда для простых случаев у нас уже будет готовая дефолтная реализация, и вместо того чтобы писать класс BookDao, мы просто заведем переменную Dao<Book> bookDao = new GenericDao<Book>().

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

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

Но у меня так получается за счет того, что я отказался от идеи POJO для классов-сущностей, и завел для них общий базовый класс с некоторыми хитрыми штучками внутри. Да, это создает зависимость, и в свете сегодняшних тенденций к уменьшению инвазивности может считаться крамолой, поэтому я такой подход никому не посоветую. Но сам втихушку буду пользоваться и радоваться, ибо очень уж удобно 

Вот такие вот мысли вслух.

Stampede, вторая часть как раз самая интересная. немогли бы вы поподробней (на примере) объяснить как вы это делаете?

А зачем нам держаться за POJO где не попадя? Я поддерживаю идею интерфейсов с разной реализацией.

Как всегда, все уже украдено до нас.
http://www.hibernate.org/328.html

Stampede
Вот, человек понял, что я хочу узнать  +1
По второй части твоего поста, о чем речь в общем и целом понятно, но действительно интересно услышать чуть детальнее.

fixxer
Хороший линк, спасибо. Сам реализовывать не пробовал?

там внизу пример, схожий на то , что Stampede и Fixxer описали.
http://www.ibm.com/developerworks/java/lib...pop1/index.html

я вопроса  не понял ?  меня игнорят ? ссылка не та что нада ?  
тогда обьясните плз, мне тоже интересно, я ж не просто так линку скинул 
  

эта ссылка уже обсудилась в теме, будь внимательней.