How can I persist and query userconnections via Hibernate in Spring Social?
The situation:
We have to introduce Spring Social in a legacy web application. This legacy system uses Hibernate. The problem is, that in Spring Social the userconnections are persisted via SpringTemplate (classes JdbcUsersConnectionRepository and JdbcConnectionRepository).
From my limited understanding, I have two options:
Use it as it is.
Implement a custom ConnectionRepository and UsersConnectionRepository, which use the existing Hibernate infrastructure
Option 1 is not what I want, as I then have to invest a lot of effort to configure properly a second persistence framework (multi-threading, connection-pooling, etc.).
Option 2 quickly solves my problems, but in the long run may lead to hidden or unhidden problems when upgrading to new Spring Social versions.
As both options are not really satisfying my question:
What would you propose? Do you know better options?
Related
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.
Currently We have an enterprise application that works with spring and JPA.
Today we are planning our next generation server.
We are debating whether to use spring-data in our project? It seems to increase productivity and development times.
Are there any alternatives to spring-data to consider? Why not using spring and JPA alone?
What do you suggest?
Bear in mind we are starting to develop from scratch so no constraints are available other than:
we use mysql and mongoDB
we code in java
we will develop client side code in GWT.
Currently we have a layered architecture.
We have a Service layer and a manager layer, which takes care for persisting and business logic. Whoever built that didn't see a good reason to insert the third DAO layer.
There are some technical benefits of Spring Data over Spring + JPA, which in a pure SQL environment, I think give Spring Data an advantage:
Spring Data uses the same CrudRepository interface for all implementations, so you'll have less effort to switch between JPA to MongoDB
Spring Data saves you writing the same methods again and again. You just add the method to the interface and it'll generate it for you (e.g. UserRepository.findByUsername())
You can save boilerplate on REST implementations for JPA, MongoDB and others (see http://projects.spring.io/spring-data-rest/)
If you wanted to experiment with other persistence or indexing services, then there are Spring Data implementations for both mature and newer technologies such as for Neo4j, Hadoop, Solr, ElasticSearch, fuzzydb.
Given that you use MySQL and MongoDB, I think Spring Data is a strong candidate, as it allows developers to code to a single data access API (Spring Data) instead of two (JPA and the MongoDB Java Client).
Regarding the existing architecture, it sounds as though your manager layer is implementing either a Rich Domain pattern, or Active Record.
Spring Data is in my view very well suited to Rich Domain when combined with injection of services using Spring's #Configurable.
Lastly, I'd say that Spring Data also gives a significant advantage when needing to implement services for things like Spring Security and Spring Social, which use MongoDB or others instead of SQL.
We did this in the fuzzydb sample webapp that can be found here. (Disclaimer: I'm the currently sole recent committer on fuzzydb, and haven't touched it for a number of years, but we did have a live service, www.fridgemountain.com, based on that code, but neglected to promote it)
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
We're in the process of redesigning a large application (web-portal). We are suppose to use existing database that they have used for their old application. Now we are planning to use CQ for hosting the pages and supporting authoring on those pages.
So as we have closed on CQ option, question comes to integrate CQ with some external frameworks like Spring (to use JDBCTemplate) or Hibernate framework to access data from database. I have following options:
Either integrate CQ with hibernate framework to leverage caching, transaction management, data object mapping etc. But catch is hibernate can only be use to access data not for other purposes like making RESTful calls that we require too.
Or integrate CQ with spring framework to leverage JDBCTemplate to access data and also spring can help me with caching, transaction management, making RESTful calls but catch is that using JDBCtemplate will cause following problems
a. LOC will increase and the code will be hard to maintain
b. Query strings are hard to maintain in case if change in table takes place
Or use both and leverage advantages of both frameworks wherever required.
Should I look forward to integrate CQ with both frameworks. If yes then question arises that what problem it will cause in terms of:
- Ease of Use
- Productivity
- Maintainability
- Stability
- Performance
- Ease of Troubleshooting
If it's data integration that you're after, CQ5 is based on Apache Sling which allows for accessing arbitrary data sources via its ResourceProvider mechanism. This was originally a read-only mechanism but read-write functionality was recently added.
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.