The original design idea was that repository should be independent of
underlaying database technique (e.g. hibernate specific stuff) There is a
lengthy motivation in
http://fornax.itemis.de/confluence/display/fornax/3.+Advanced+Tutorial+(CSC)#3.AdvancedTutorial%28CSC%29-HowtoGenerateRepositories
Advanced Tutorial - Repositories
I'm prepared to revise that decision if we can find a solution that
simplifies things. Personally I always use
generate.repository.jpaSupport=true
to get access to to entity manager in repository and write some jpa queries
in repository.
But, when native sql or hibernate specific features are needed I prefer to
push that down to access object.
I think that if we do as you suggest we must consider two things.
1. Is it possible to solve type parameters for the generic access factory.
Maybe with Spring 3.0.
2. Dependencies between packages. I'm allergic of circular dependencies. I
think repositoryimpl and accessimpl packages must be collapsed to same
packge, i.e. repositoryimpl.
An example:
Entity Planet {
String name key;
String message;
Repository PlanetRepository {
findByKey;
save;
someNativeQuery => AccessObject;
}
}
This is how it is generated today
domain
- PlanetRepository (interface)
repositoryimpl
- PlanetAccessFactory (interface)
- PlanetRepositoryImpl
- SomeNativeQueryAccess (interface)
accessimpl
- PlanetAccessFactoryImpl
- SomeNativeQueryAccessImpl
Dependencies:
accessimpl -> domain
accessimpl -> repositoryimpl
repositoryimpl -> domain
Do you have time to try the idea?
Thanks for your suggestion.
/Patrik
PaloT wrote:
>
> Hi Patrik,
> today we spoke little bit about Repository -> AccessFactory -> Access
> chain with my college. And I didn't find good reason why we need to
> generate AccessFactory for each type. Shouldn't we replace it with
> generic AccessFactory and when specific code (specific accessImpl)
> will be necessary we will generated it to RepositoryBase. This way we
> will save AccessFactory interface and AccessFactoryImpl. I guess here
> is no problem if RepositoryBase is persistent technology specific
> (Hibernate/JPA/...).
>
> Pavel
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Fornax-developer mailing list
> Fornax-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fornax-developer
>
>
--
View this message in context:
http://old.nabble.com/AccessFactoryImpl-tp29606342s17564p29614727.html
Sent from the Fornax-Platform mailing list archive at Nabble.com.
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Fornax-developer mailing list
Fornax-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fornax-developer
