Does anyone know any Java frameworks that follows the repository approach with automatic implementation of query methods (e.g. findByNameAndLastName(…)) but not tied to Spring, only pure JPA. Such feature also exists in GORM. I would like to see if there is any project that can be used in Guice or pure JavaEE environment without bringing Spring as a dependency.
(Disclaimer: I am the author of Spring Data JPA)
There is the CDI Query Module which is very similar to what Spring Data JPA. There's also a DeltaSpike module.
Note that Spring Data JPA ships with a CDI extension that creates repository proxies as plain CDI beans and does not bootstrap a Spring container. There are APIs that allow the creationg of repository proxies programmatically such as:
EntityManager em = // … obtain EntityManager
JpaRepositoryFactory factory = new JpaRepositoryFactory(em);
UserRepository repository = factory.getRepository(UserRepository.class);
Yes, it still requires Spring libraries to be present on the classpath but it is then using them similar to how you would use Commons Collection or the like. We try not to reinvent the wheel and the Spring libraries we depend on provide a lot of useful code that we do not have to re-code.
So if it's Spring as DI container you're worrying about, feel free to give the CDI extension of Spring Data JPA a choice. If you don't want to use any Spring whatsoever (for whatever reason), have a look at the alternatives.
Based on Oliver's information, followed up as also interested in this topic --
CDI Query joining Deltaspike mail thread: http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Porting-the-CDI-Query-extension-project-to-DeltaSpike-td4329922.html
Deltaspike base link: http://deltaspike.apache.org/index.html
Getting started: http://deltaspike.apache.org/documentation.html
Just did their 0.4th release as of 5/31/2013.
However, have not done enough of a review to contrast/compare Deltaspike versus Spring-Data w/ CDI extensions (spring-data being very mature).
Take a look at Tomato on github!
It is a functional replacement for Spring JPA, has zero dependencies, performs better and is far easier to use. It will reduce your data access code by 98% and deliver the results you want right out of the box.
https://rpbarbati.github.io/Tomato.
If you want free, fully functional dynamic forms and/or tables for any Tomato entity or hierarchy, that can also be customized easily, try the angular based companion project...
https://rpbarbati.github.io/Basil
Both are current, maintained projects.
Try it yourself, or contact the author at rodney.barbati#gmail.com with questions.
Related
I am using Hexagonal Architecture, Hibernate Reactive with Panache and Quarkus in a Kotlin Project.
Transaction boundaries are set using #ReactiveTransactional annotation.
The problem is that I had to add the whole Hibernate Reactive with Panache dependency in the domain and application layers just to make this annotation available.
Is there a way to avoid this?
I was hoping it would be possible to create a domain annotation and then in the adapters layer replace it with the #ReactiveTransactional somehow.
You could remove the annotation from the class, and wrap it into a service, and implement this service in the adapter layer using the annotation.
Don't use database related dependencies inside the hexagon.
The idea is to decouple the business logic from the user interface and infrastructure. Database logic should be placed into an adapter.
It theory it sounds great, in practice that means tons of mappers i.e. boilerplate code. On the bright side you have a Kotlin, and not a Java project so this should be a bit less tedious than the alternative. Bear in mind that there are projects such as Dozer, MapStruct that can make the mapping process easier.
We are creating a web based application using, JSF (Primefaces as presentation library) and Spring Data JPA for data access tier. And the project is Spring Boot enabled.
The project is divided into multiple modules (according to tiers), and one of them is the presentation tier.
Do you suggest creating a dependency from presentation tier to Spring Data (so have access to PageRequest and Slice and ... classes) or not?
Otherwise we shall re-implement these classes in this tier and convert them to Spring Data classes, which seems some how verbose.
Do you suggest creating a dependency from presentation tier to Spring Data (so have access to PageRequest and Slice and ... classes) or not?
Every decision you make will have it's Pros and Cons and it really depends on your specific situation if this is a problem or not.
I see the following things in favor of a dependency:
reuse of PageRequest and similar classes. They represent concepts that are needed when working with persistence but aren't really persistence specific. Therefore there is really no point in duplicating them.
On the other hand, Spring Data contains many classes that don't have any business in a presentation layer. For example, those dealing with creating repositories.
Your task is to determine if the risk/damage of having those classes around is bigger than the benefit of having PageRequest and co available.
With all teams and projects I worked with so far I'd opt for just having a dependency.
Here is why:
The domain has a dependency on JPA and Spring Data anyway. So by depending on the domain-layer, you get a transient dependency, no matter if you want or not.
The persistence specific classes inside Spring Data are so specific that I never experienced anybody trying to use them directly.
Note that especially the first point assumes that you are not copying over your JPA entities in separate transport objects, which would kind of negate the benefits of JPA.
We are currently using Spring 3.2.3 + JPA (Hibernate). We use aspects for transaction support as opposed to annotations. We write out own entity services (read: repositories) to abstract the persistence away from our application.
I've read a lot about Spring Data and feel it would make our code considerably cleaner and more robust. I wonder though, are there any gotchas that I should consider before transitioning?
Thanks
If you're already on JPA the transition should be as easy as it can be: activate the repositories, point the infrastructure to your EntityManagerFactoryBean and off you go.
Transactions should just work fine as well. The annotation based usage within Spring Data is selectively activated for the repository beans only. They are configured to take part in existing transactions by default, so any custom larger scoped transaction setting should be in effect already.
I'm starting a new Spring project and have decided to try out Spring Roo. In setting up the persistence layer, I see that Spring Roo supports (actually even defaults to) the ActiveRecord pattern. While I have always been a DAO/DTO fan in the past, Roo makes a very good case for using the ActiveRecord pattern, as it seems to "hide" most of the ActiveRecord methods in the apsect files.
Does anybody know why the Spring Roo developers would default ROO to use the AR pattern when Spring Data does such a beautiful job of providing/hiding CRUD (the typical bain of DAO patterns)? Is Spring trying to push more people to use the AR pattern instead of the Repo pattern?
I believe this was because the ActiveRecord paradigm from the Rails/Ruby camp showed alternatives to the full stack we are used to. Here is how the Spring team puts it:
We have removed the DAO layer because it is not strictly essential to
creating the typical web applications that most people are trying to
build
It's also worth observing that most modern RAD frameworks avoid DAO
layers and add persistence methods directly to entities. If you
compare similar technologies to Roo, you will see this avoidance of a
DAO layer is commonplace, mainstream and does not cause problems.
Source: http://static.springsource.org/spring-roo/reference/html/architecture.html#architecture-dao
That said, I've used Roo with the class application tiers with success. The advantage is that it feels more "Spring"y, and since we can remove Roo and inline all the IDTs, long term maintenance may be simpler.
More recently, I'm using the ActiveRecord way because the Roo shell still doesn't support dynamic finders when using repositories. I'm not hopeful that they will get around to it anytime soon:
https://jira.springsource.org/browse/ROO-2694
There are two entity manager factory beans in Spring that would work for my application. The org.springframework.orm.jpa.LocalEntityManagerFactoryBean and org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean. I am using Spring 3.0 with EclipseLink JPA 2.2.
What I've read about these two are that they are the same. Except that LocalContainerEntityManagerFactoryBean uses weaving. What is it? And, why would I want to use it?
"Weaving" is a term for program transformation, usually heard around "aspect oriented programming" area. The transformation is usually not done to the source but the .class (the bytecode) and a techy term for changing bytecode is "bytecode instrumentation".
why would I want to use it?
The JPA implementation you use may rely on such bytecode instrumentation for some features it provides and hence you might be forced into using it.
And for weaving to work correctly, you might need to specify a -javaagent: For eg,see section 'Eclipse Junit' here.
It looks like LocalContainerEntityManagerFactoryBean allows you to configure a weaver implementation ( one of DefaultContextLoadTimeWeaver, GlassFishLoadTimeWeaver, InstrumentationLoadTimeWeaver, OC4JLoadTimeWeaver, ReflectiveLoadTimeWeaver, SimpleLoadTimeWeaver, WebLogicLoadTimeWeaver
at an XML file, instead of relying on a -javaagent runtime argument.
This configuration isn't such a big factor, I'd guess.
Other features which the docs explain, sound like deciding factors.
LocalEntityManagerFactoryBean bootstrap is appropriate for standalone applications which solely use JPA for data access. If you want to set up your persistence provider for an external DataSource and/or for global transactions which span multiple resources, you will need to either deploy it into a full Java EE 5 application server and access the deployed EntityManagerFactory via JNDI, or use Spring's LocalContainerEntityManagerFactoryBean with appropriate configuration for local setup according to JPA's container contract.
If you plan on deploying your application to an Application Server and letting the Application Server manage the Entity Manager Factory and Transactions than the LocalContainerEntityManagerFactoryBean might be a better option. If you rather have the Application be more isolated, than the LocalEntityManagerFactoryBean would be more appropriate.
This blog can help provide more insight: http://second-kind-demon.blogspot.com/2011/06/spring-jpa-java-ee-jboss-deployment.html