Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have to admit that I didn't have the luck to use JPA, so If my question will sound weird please don't blame me. AFAIK Hibernate seems to be a wide spread implementation of JPA. The question is: Are there any cases where importing Hibernate can be avoided? My boss said that we haven't to "overhead" our project with external things and could implement the necessary features of JPA ourselves. But almost everybody says that reinventing the wheel is just senseless and recommend to use ready implementations of JPA. Now I'm a bit confused and don't know what is the best way to go.
Depends on the scale of your project: the cost of learning hibernate vs the cost of rolling your own persistence mechanism.
Also worth considering other payoffs: will you be likely to use hibernate in the future? Then the time invested will be worthwhile.
On the other hand it is always good to eliminate 3rd party dependencies where possible. If your problem is small, an external library can often provide an unnecessary layer of indirection when trying to diagnose issues.
More on the topic here: http://www.joelonsoftware.com/articles/fog0000000007.html
It depends on what you actually do with the database. If you mainly work with highly tabular data and you rely much on bulk queries then JPA will not be that useful and if you have no prior experience it will be hard to use it effectively.
If on the other hand you are manipulation complex object structures that need to be persisted then JPA is very useful.
Note that Hibernate is not the only JPA provider. So maybe your boss would be happier with for instance EclipseLink as this is the reference implentation.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
When I chat to stackoverflowers on chat and read other tutorials about database with Java then they are guide me to use JOOQ instead of HIBERNATE.
I am totally aware about ORM with Hibernate and I prefer to use Hibernate and now aware almost about JOOQ by reading tutorials and implementation on small projects.
But I am confused what to choose and what is perfact for my dynamic web-applications which can be larger,medium or smaller, either Hibernate or JOOQ ?
BTW googled a lot but confused more and more...!!!
Just Like : this,this and this.
Which one is best for different conditions and situations for developer.?
While jOOQ and Hibernate compete for the same target audience, they do not solve the same problem at all. You've already linked this article in your question. The essence of it is simple:
Are you going to solve object graph persistence problems? Use an ORM (e.g. Hibernate)
Are you going to embed SQL into Java? Use SQL (e.g. jOOQ)
Of course, since both APIs cover accessing relational databases, they overlap in functionality to a certain extent. E.g. Hibernate also supports simple querying, while jOOQ also supports simple mapping.
While we should avoid delving into subjective discussions about whether object graph persistence or SQL is a better approach at interacting with your database, I think the above is a pretty objective answer to what API is better suited, once you've made the subjective decision.
AND: You can use both, e.g. ORM/Hibernate for CRUD, SQL/jOOQ for reporting.
(Disclaimer: I work for the company behind jOOQ, so this answer is biased)
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
How to use ORM technologies in fully grown existing multi threaded java database app?
Application is developed nearly 7 years back. It has got Business object and DAO.
is it feasible? Now our application faces connection bottleneck and data integrity issue because of multi threaded database access. This occurs at highly concurrent situations.
how to synchronize insert or update in same table my multiple thread.?
I know it can done by setting isolation level which may affect performance (TRANSACTION_SERIALIZABLE). But thought of re structuring the application for scalability. May be using ORM.
If you are managing (getting/releasing) database connections correctly using JDBC (I believe you use this), then using a ORM will not help you at all, because ORM will not do any magic about resource management. It just gets and releases resources at proper points (if it is configured properly).
By the way if you have developed your project using JDBC and SQL, it will be lots of work to change it to an ORM such as Hibernate or JPA.
If you are not sure that your resource management is correct, use Spring JDBC (JdbcTemplate). It ensures that resources are always released properly, and well it is JDBC, and it can be less work to do for your project.
You can use ORM for multi-threaded java applications. But if you already have data integrity issues then ORM will not help a lot, except you also add locking. (JPA provides support of optimistic and pesimistic locking.)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I got this Java webapp (JSP+Struts+Hibernate+MySQL+tomcat6) in which there are like 20000 users right now and the number is growing up rapidly. I have to rank all the users periodically. The ranking process involves lots of objects and hibernate actions and it's fairly heavy. Talking java, unfortunately I must iterate on all of the users and apply this procedure in them one by one. this method sucks out lots of the server's resources.
on the other hand I might be able to run all these actions in a stored procedure on the MySQL side. I'm pretty sure the code there will be a complete mess and troublesome to modify later on. although the performance would be much more better this way but software engineering principles wouldn't take this solution nicely.
what do you suggest?
This is obviously much more efficient in SQL. The real problem is that you are using hibernate and so have lost control over your schema which is why a solution like iBatis, although less popular, makes more sense - because it allows you to switch to SQL when that is the more appropriate tool for the job.
Given that you have chosen hibernate, are you sure that you can't push the API it provides into doing this? Have you looked in detail at the criteria API? That includes associations - it might be possible to shoe-horn what you want in there and so keep the logic more closely associated with the classes. http://docs.jboss.org/hibernate/stable/core/reference/en-US/html/querycriteria.html
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am making some small "business intelligence" applications/tools that need to talk to other systems. Primarily accounting systems that believe that databases are an integration layer (or are too lazy to provide an api).
What's the easiest way of getting specific data out of a third party database and into my Java objects?
Notes:
(I am now bolding the points below that have not been directly answered)
This is absolutely a read only situation. I would prefer a solution that cannot write.
Depending on speed and/or aggregation requirements, I may want/need to store these records at a future point. (This may or may not impact on solutions like hibernate which would have difficulty reading from one db and writing to another)
The first cut would be a very select partial object population (I have generated my objects from an xml schema, and the database will only need to supply 30% of the possible fields etc)
The first db integration target is (Visual?)FoxPro - hence point 2.
I am currently developing primarily in Java, but expect that to change to scala soonish (can LINQ help here?)
The standard of mapping db schema to objects (and vice versa) is the Java Persistence API. There are several implementation like Hibernate and EclipseLink (and others). I can't tell for all of them, but hibernate an eclipse plugin called hibernate tools, which can generate Java classes from the schema. You can find instructions here
JPA has its own query language called JPQL, Hibernate supports an extended version of it called HQL. Both looks like SQL, applied to objects.
I suggest you take a look at ScalaQuery, if you are doing Scala code.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've used Spring and Spring.NET quite a bit, but I would like to see what else is out there. Can anyone recommend a good Java or .NET framework that I could try to learn?
Here is a list of IoC containers from the good Mr. Hanselman...
Castle Windsor is very popular, you could do worse than learn that.
On the .Net side, Ninject is probably the most interesting, on the Java side, I would say check out Google Guice. That being said, DI is DI, and they all more or less do the same thing. The differences are mostly in how they are configured.
Google Guice is very good - unless you really need it, there are no .xml configuration files - everything is done via annotations, and in an ideal world you can avoid setter methods, injecting your dependencies via the constructor.
I'd suggest JBoss Seam. It has a very different dependency injection model than Spring. Seam's DI is bidirectional and able to inject values at every stage in an object's life (not just during initialization).
It's certainly not a good for everything, but if your looking to try different things in DI, this is interesting.
Look at Seam's home page.
So in the wide world of software you feel the need to learn what is 'assumed plumbing' rather than expand your base? You just use IoC. It's not even optional for anyone serious. This is going on like a decade now.
Go master Functional Programming in say F#. Master the new IObserver and related work coming in .NET 4.0 as the conceptual pairing to IEnumerable. Write a domain specific language for your domain of choice. Create New abstractions, don't simply relearn old ones.