The goal of the Polyforms project is to remove the heavily duplicated glue code to tie data access objects to the underlying persistence API. The approach used in the framework is to automatically implement service methods on a Repository interface defined by the developer. Methods defined on the interface are, by default, linked to database operations via naming conventions. For example, the wiki discusses how to implement a repository for a User entity object. First, the API for the repository must be defined:
public interface UserRepository extends EntityRepository<User, String> {
@Finder
List<User> findByCreator(User creator);
}
The @Finder annotation marks the method for Polyforms. Rather than creating an implementation for the UserRepostiory, however, a matching Hibernate query needs to be provided on the User entity via another annotation.
@NamedQueries({
@NamedQuery(name = "User.findByCreator", query = "select u from User u where u.creator = :creator"),
})
public class User {
...
}
As per the documentation, the convention used to find queries is based on the method name, as well as the name of the entity itself:
The rule for mapping method with Named Query is [name of Named Query] = [name of Entity].[name of method]. you can specify the name of Named Query in @Finder as @Finder("findUserByName"), then the name of Named Query will be "User.findUserByName".
In addition to the @Finder annotation, there is also an @Updater and a @Counter annotations to provide support for mass updates and counting queries respectively. The
EntityRepositoryparent interface already provides support for saving single entities, deleting, and retrieving by identifier.
All of this wiring is done via the
Spring frameworkand relies on Spring aspects to be able to provide runtime implementations of the APIs.
Other functionality supported by Polyforms includes:
- Automatic management of tracking information (created by, created date, modified by, modified date)
- Transparent pagination support
- Definition of transaction boundaries via annotation
- Domain event model to decouple persistence events from application functionality
More information is available on the
Polyforms wiki.
Community comments
Huh?
by Ilja Preuß,
Re: Huh?
by George Gr,
Re: Huh?
by ding jack,
Re: Huh?
by Kuisong Tong,
Re: Huh?
by Ilja Preuß,
Add this to Spring framework
by Vineet Bhatia,
another annotation based DAO
by Mert Can Akkan,
Take a look at Hades project
by Oliver Gierke,
Re: Take a look at Hades project
by Mario Gleichmann,
Re: Take a look at Hades project
by Oliver Gierke,
Re: Take a look at Hades project
by Kuisong Tong,
Re: Take a look at Hades project
by Pete the Wheat,
Re: Take a look at Hades project
by Oliver Gierke,
Arid POJOs provides generic DAOs with dynamic finders for Hibernate
by Chris Richardson,
Similar things I have done
by Shum Adrian,
Re: Similar things I have done
by Oliver Gierke,
Re: Similar things I have done
by Kuisong Tong,
Re: Similar things I have done
by Shum Adrian,
Huh?
by Ilja Preuß,
Your message is awaiting moderation. Thank you for participating in the discussion.
I don't understand why the queries are declared on the user class - this seems to defeat the whole purpose of using DAOs/Repositories in the first place, namely decoupling the domain objects from persistence logic...
Re: Huh?
by George Gr,
Your message is awaiting moderation. Thank you for participating in the discussion.
The queries are declared on the user class, because this is the JPA specification.
I like the idea.
Add this to Spring framework
by Vineet Bhatia,
Your message is awaiting moderation. Thank you for participating in the discussion.
Spring Framework ORM and DAO could use some ideas from this.
another annotation based DAO
by Mert Can Akkan,
Your message is awaiting moderation. Thank you for participating in the discussion.
I although there is no open implementation yet here is another ways of NOT implementing DAO layer
www.altuure.com/2008/10/02/who-needs-implementa...
have fun
Re: Huh?
by ding jack,
Your message is awaiting moderation. Thank you for participating in the discussion.
JPA sucks!
Re: Huh?
by Kuisong Tong,
Your message is awaiting moderation. Thank you for participating in the discussion.
queries can be defined in other file. In user class, the benefit is all things in one place.
Take a look at Hades project
by Oliver Gierke,
Your message is awaiting moderation. Thank you for participating in the discussion.
There is an open source project called Hades that provides this facilit, too. Actually in our case it is neither necessary to mark the method with an annotation. Additionally we offer constructing the query from the finder method's name if no NamedQuery was found:
findByUsername on a UserDao for a User class would result in from User u where u.username = ?
Of course this is only suitable for very rudimentary queries but you can always override this with a namedquery.
Furthermore Hades seems to offer more sophisticated support like auditing and a Spring namespace to easy configuration.
trac.synyx.org/hades
Regards,
Ollie
Re: Take a look at Hades project
by Mario Gleichmann,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hey Ollie,
i just did some investigations on Hades over the weekend.
God job!
For all others, interested in that topic - i would definitely take a closer look!
Greetings
Mario
Re: Take a look at Hades project
by Oliver Gierke,
Your message is awaiting moderation. Thank you for participating in the discussion.
> God job!
I'm not that overwhelming but appreciate your congratulations ;).
Regards,
Ollie
Re: Huh?
by Ilja Preuß,
Your message is awaiting moderation. Thank you for participating in the discussion.
Well, I guess I simply wouldn't call "all things in one place" a benefit. Anyway, it's good to know that there is an alternative. Obviously, I'm not very knowledgeable about JPA, so thanks for the input!
Arid POJOs provides generic DAOs with dynamic finders for Hibernate
by Chris Richardson,
Your message is awaiting moderation. Thank you for participating in the discussion.
Back in 2007, I blogged about Arid POJOs (code.google.com/p/aridpojos/), which provides generic DAOs for Hibernate. When an abstract finder is called, Arid will either invoke a named query with the same name or parse the method name using an approach similar to dynamic finders in Grails GORM and Active Record. We have used it on several projects over the past 18 months and found that it has significantly reduced the amount DAO code that we need to write.
Chris
Re: Take a look at Hades project
by Kuisong Tong,
Your message is awaiting moderation. Thank you for participating in the discussion.
Generic DAO just one big feature in Polyforms, Others include Delegator(auto conversion between DTO and Model), Domain Event(@observer in method like in c#).
Re: Take a look at Hades project
by Pete the Wheat,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hades looks interesting indeed, but version 0.2... :)
Re: Take a look at Hades project
by Oliver Gierke,
Your message is awaiting moderation. Thank you for participating in the discussion.
@Pete
I agree, that you consider libraries in detail, especially if it touches the core of your application. But I guess you wouldn't blindly follow a "1.0" tag without testing it, would you? ;)
So feel free to play with it a little, push the boundries and don't hesitate to comment on things you don't like :).
@Kusiong
Yes, I've browsed through the project repository a litte. I especially like the idea to map DTOs against domain object automatically. We seem to have some overlaps but guess we can surely find other projects out there that implemented this idea. So keep up the good work!
Regards, Ollie
Similar things I have done
by Shum Adrian,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think we are both inspired by
www-128.ibm.com/developerworks/java/library/j-g...
In my current project, we do adopted a similar framework, with a lot of things extra. In fact I am also planning to tidy it up and release a generic dao framework later if I have time.
Base on what I did, there are some comments on what u described here:
1) You gotta have annotation for input argument to 'map' it to the named parameter place holder. By reflection I think there is no way to get the input argument name
2) Base on our experience, putting the query as named query, is hard to debug if there is syntax error. We use Hibernate + Spring and result of incorrect named query is just a bunch of non-understandable errors. Therefore in my own framework, I provided @Query(query="your query") to annotate the finder method, and as the query is really executed in runtime, we get the understandable error of telling us what's wrong on the query.
3) Sql query and self-implementing finder method should also be provided as there are always cases that is hard to represent by a single HQL.
Interesting enough, we have also developed a primitive annotation base Model-DTO mapping tools. By certain annotations in the DTO side, it build DTO base on model object passed in, and incoming DTO back to model.
Basic idea on the DAO framework is shared, though in Chinese, in my blog: adrianshum.blogspot.com/ (in case u have interest)
Re: Similar things I have done
by Oliver Gierke,
Your message is awaiting moderation. Thank you for participating in the discussion.
Considering 1). Actually you can if the code was compiled with debug flag enabled. Spring provides a LocalVariableTableParameterNameDiscoverer (static.springframework.org/spring/docs/2.5.x/ap...) to do this.
Regards,
Ollie
Re: Similar things I have done
by Kuisong Tong,
Your message is awaiting moderation. Thank you for participating in the discussion.
@Adrian
1)Polyforms use convention: The parameters in method should order by name in NamedQuery.
2)We always add NamedQuery to Entity, so hibernate (or other JPA implementation) help us check the syntax during startup.
3)Polyforms has a function named query like QBC, developer write HQL like
<![CDATA[select u from User u
where 1=1
/~ and u.name like {%name%} ~/
/~ and u.email like {%email%} ~/
/~ and u.createdTime >= {createdTimeFrom} ~/
/~ and u.createdTime < {createdTimeDue} ~/
order by u.userName
]]>
and system will remove clause between /~ and ~/ when the parameter is null.</![cdata[select>
Re: Similar things I have done
by Shum Adrian,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Kuisong
1) we considered such convention before, but in real world development it is too restrictive and not that feasible. Developer may bind same param multiple times. And DAO's method signature shouldn't depends on the actual query. However in some case it is hard to move the named param around.
2) That's the main problem we faced. Yes, hibernate checked and tell us that it cannot be started up because there is problem, but as far as I remembered, it doesn't tell much on what cause the failure. Which is very troublesome, especially someone write a incorrect named query, and all DAO related unit tests failed.
3) Interesting enough, we also did similar things :) We called it dynamic query and is put in our @Query (similar to your @Finder). we do something like select balbalbla from User u where 1=1 {and:bindparam1 u.val = :bindparam1}
(We make it works for both SQL and HQL too)
However, still there are cases that finder method is unable to present by a single query. Therefore considering leaving flexibility to developer to let them write DAO finders in traditional way is a must if u want to make the framework use-able in real world development :)