As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am developing a web app in java. I am thinking of using Spring MVC. But at ORM side, I have a decision to make. I have studied about ORMs like Hibernate,iBatis, Spring JDBC Template etc.
I find iBatis and Spring JDBC Template (using RowMapper) are almost same, where you map each query to an object. So you have to write a class for each query.
In Hibernate, you map each table with a class.It reduces the need to write SQL.
I guess Hibernate is preferable when you are not good in SQL.In my case, I am quite comfortable in SQL, so want to use iBatis or Spring JDBC Template which will give me good control over SQL and these are less complex than Hibernate.
But Hibernate provide caching which other ORMs do not provide.
So my questions:
Which one to use between iBatis and Spring JDBC Template?
Is Hibernate caching (or any other Hibernate feature which I do not know) so good that I should go with Hibernate instead of other ORMs?
I guess Hibernate is preferable when you are not good in SQL
I disagree with the idea that you should use Hibernate, or any other ORM because you're not very good at SQL.
Whilst it's true that Hibernate will generate your SQL for you, not understanding what it's doing is a recipe for a performance disaster.
As a Hibernate developer I am pretty good at SQL too ;) In fact the beginning of my career was working exclusively with relational (and even some pre-relational) databases. Anyway I really don't get this misconception that hand writing SQL being "more maintainable" or giving "better control". But if you do buy into that misconception then you can actually tell Hibernate the SQL you want it to use for all CRUD operations pertaining to each and every entity (see #SQLInsert, #SQLUpdate, etc).
Again, I find that not nearly as maintainable. Personally, I would much rather have Hibernate manage the INSERT/UPDATE/DELETE SQL for me. Loading data on the other hand is a situation where I generally want a little more control. But Hibernate (and JPA providers in general) already give you this kind of control through HQL/JPQL and Criteria queries. In my opinion, if you are relying on Session.get you are simply asking for bad performance. And that has nothing to do with using O/RM. That's just not good data loading plan because the amount of data you need (even related to the same entity) is different based on the application use case. For example, loading Employees for a drop-down list requires much different amount of data from generating a departmental roster. And thats the control.
By all means use what feels most comfortable to you and meets the goals/requirements of the application. Just make sure your comparison points between technologies and products are factual and not just misconception.
Caching is a fair point with regard to O/RM. In fact JPA (as of 2.0) requires some level of caching. However, be aware that caching at the O/RM level often leads to worse performance. You really need to understand the semantics of the particular data you would like to cache. Some data is good candidate for caching, some are not. Also, it is often much better to cache "above" the O/RM level.
Personally I would choose Hibernate because I believe (1) it strikes the best balance between abstraction while still giving access to SQL power (this is largely true of JPA providers in general) and (2) it has the most complete feature set of any persistence provider out there.
Well, your choice should depend of what you are developing the application for. I would say that Hibernate is the more powerful among the above mentioned ORMs and has a strong community and caching is really strong. But really strong caching is sometimes a problem and has it's memory intensive.
Am a myBatis user and believe it's a mid-way and provides all that you need. Well, myBatis would be my personal choice over Spring JDBC template.
Related
When we talk about spring (which ever module say jdbc), one of the reasons we use it is because it enables dependency injection and controls lifecycle of beans/classes. In programming, one of the most important fundamental is to code for interfaces rather than implementations, so today if I am using sql server driver v1, I can change it to v2 tomorrow if my code is written in such a way that it cares about Driver interface and not the implementations, then in what case would I ever need coding over configuration ?
The wording of your question seems a bit strange to me. Perhaps you are asking if there are any drawbacks to using Spring-like dependency injection. I can think of a few drawbacks, but whether these drawbacks outweigh the potential benefits of Spring is a matter of opinion.
Unfortunately, a Spring XML file is much more verbose than code to achieve similar (but hard-coded) initialisation of objects.
A programmer has to look not just at code but also at a Spring XML file to figure out what is going on. This, arguably, is a form of the Yo-yo problem.
One significant benefit of Spring is that it can be used to instantiate and configure any Java class (assuming the classes provide getters and setters). In particular, Java classes do not need to be polluted with the need to inherit from framework infrastructure classes. If you don't mind polluting classes with the need to inherit from framework infrastructure, then it is possible to have much more concise configuration files for instantiating and configuring objects. A case study illustrating this idea can be found in Chapters 9, 10 and 11 of the Config4* Practical Usage Guide. I am not proposing that the approach used in that case study be used for all applications, but I think it is a good approach to use when there is a complex, standardised API (such as for JMS) that is implemented by multiple products. In the case study, the approach results in a significantly easier-to-use API and eliminates some potential bugs from applications. Spring doesn't offer such benefits.
Section 9.4.2 of the Config4* Practical Usage Guide outlines a 9-step initialisation process for typical JMS applications. The framework library discussed in the case study ensures that those 9 steps are carried out in the correct order. It has been years since I looked at Spring so I might be wrong, but I don't think Spring has the flexibility to (easily or perhaps at all) enforce such a complex 9-step initialisation mechanism.
Is it sensible to use Spring in the server side of an in memory data grid based application?
My gut feeling tells me that it is nonsense in a low latency high performance system. A colleague of mine is insisting on including Spring in it. What are the pros and cons of such inclusion?
My position is that Spring is OK to be used in the client but it is too heavy for the server, it brings too many dependancies and is one more leaky abstraction to think of.
Data Grid systems are memory and I/O intensive in general. Using Spring does not affect that (you may argue that Spring creates a lot of beans but with proper Garbage Collection tuning this is not a problem).
On the other hand using Spring (or any other DI) helps you structure and test your code.
So if you are using implementing some sort of server based on Data Grid systems, pay attention to properly adjusting GC, sockets in your OS (memory buffers and socket memories). Those will give you much more benefits than cutting down DI.
First, I'm surprised by the "leaky abstraction" comment. I've never heard anyone criticize Spring for this. In fact, it's just the opposite. Spring removes the implementation details of infrastructure such as data grids from your application code and provides a consistent and familiar programming model, allowing you to focus on business logic. Spring does a lot to enhance configuration and access to data grids, especially Gemfire, and generally does not create any runtime overhead per se. During initialization of a Spring application, Spring uses tools like reflection and AOP internally which may increase the start up time of an application, but this has no impact on runtime performance. Spring has been proven in many high-throughput, low-latency production applications. In extreme cases, things like network latency and serialization, concerns external to Spring, are normally the biggest factors affecting performance.
"Spring brings in too many dependencies" is a common complaint, but is a fallacy. I would say Spring brings in the exact right amount of dependencies for what it needs to do. Additionally, Spring Boot starters and the platform BOM do a lot to simplify dependency management so you don't need to worry about version incompatibilities or explicitly declaring common dependencies. I'll have to side with your colleague on this one.
I have not used Spring Data before but I've used Hibernate ORM a number of times for MySQL based application. I just don't understand which framework to choose between the two for a MongoDB based application.
I've tried searching for the answer but I can't find the answer which does a comparison between the two in a production environment. Has anyone found problems working with these two frameworks with MongoDB ?
Disclaimer: I am the lead of the Spring Data project, so I'll mostly cover the Spring Data side of things here:
I think the core distinction between the two projects is that the Hibernate OGM team chose to center their efforts around the JPA while the Spring Data team explicitly did not. The reasons are as follows:
JPA is an inherently relational API. The first two sentences of the spec state, that it's an API for object-relational mapping. This is also embodied in core themes of the API: it talks about tables, columns, joins, transactions. Concepts that are not necessarily transferable into the NoSQL world.
You usually choose a NoSQL store because of its special traits (e.g. geospatial queries on MongoDB, being able to execute graph traversals for Neo4j). None of them are (and will be) available in JPA, hence you'll need to provide proprietary extensions anyway.
Even worse, JPA features concepts that will simply guide users into wrong directions if they assume them to work on a NoSQL store like they were defined in JPA: how should a transaction rollback be implemented reasonably on top of a MongoDB?
So with Spring Data, we chose to rather provide a consistent programming model for the supported stores but not try to force everything into a single over-abstracting API: you get the well-known template implementations, you get the repository abstraction, which works identical for all stores but lets you leverage store-specific features and concepts.
Disclaimer: I'm one of the Hibernate OGM developers so I'll try to provide some of the reasons behind it.
Hibernate OGM provides Java Persistence (JPA) support for NoSQL solutions. It reuses Hibernate ORM’s engine but persists entities into a NoSQL datastore instead of a relational database. It also aims to provide access to specific datastore features when JPA does not have a good fit.
This approach is interesting for several reasons:
Known semantic and APIs. Java developers are already familiar with JPA, this means that one won't have to learn lower level API. It also supports both HQL and native backend-queries.
Late backend choice. Choosing the right NoSQL datastore is not trivial. With Hibernate OGM you won't have to commit to a specific NoSQL solution and you will be able to switch and tests different backends easily.
Existing tools and libraries. JPA and Hibernate ORM have been around for a while and you will be able to reuse libraries and tools that uses them underneath.
Most of JPA logical model fits. An example of a good fit is #Embedded, #EmbeddedCollection and #Entity (that can be a node, document or cache based on the datastore of choice). Admittedly, annotation names might be strange because you will also have to deal with #Table and #Column.
JPA abstracts persistence at the object level, leaving room for a lot of tricks and optimizations. We have several ideas planned, like polyglot persistence: storing data in several data stores and use the best one for a specific read job.
The main drawback is that some of the concepts of JPA are not easily mapped to the NoSQL world: transactions for example. While you will have access to transaction demarcation methods, you won't be able to rollback on data stores that don't support transactions natively (transactions, in this case, will be used to group operations and try to optimize the number of calls to the db).
Also, if your dataset is by nature non domain model centric, then Hibernate OGM is not for you.
One can Just go with SpringData. If you recall Spring ORM also uses some JPA things such as Entity, Transaction and provided best commination of things from JPA and Hibernate APIs a. Spring community will take care in future versions if JPA is getting more matured for NoSQL.
Though it is not the main reason. Most of reasons are described by #Oliver Drotbohm.
Read more documentation of SprinData and further analyse your data model, scalability on continuity/growth of data store, find best fit for your solution and consider suggestion given by #Davide.
Many cases SpringData has got more success rate than JPA while integrating with MongoDB.
I'm working on a Java EE Application, and I use Spring as framework.
Now I've seen people talking about ORM Frameworks (Hibernate/JPA/iBatis...) but I don't know what might be the reasons to use those frameworks?
I mean what those frameworks will change in the project functions & performance?
if you can give me a clear example it will be great.
Since you will get bored by writing the SQL insert/update/select statements for entire java objects and keep the Object <-> SQL code in shape when your object changes. JPA is actually a part of the Java EE standard.
However, it will not provide any means to keep you from knowing what you are doing with the database, except for very simple cases. My experience is that any JPA framework will add just another layer of complexity to performance issue track down and debugging.
In the end, you might end up need to understand how JPQL (SQL-ish syntax for JPA) translate into SQL for every combination of JPA provider (OpenJPA, HIbernate, eclipse link..) and datbase implementation. This will be non trivial.
If you have no specific performance requirements and just want easy object persistance, give it go! Hibernate seems to be state of the art atm.
To avoid writing your own SQL for everything, and to [partially] bridge the object-relational gulf ("abyss").
For simple requirements, ORMs are great, and make thinking about some DB stuff go away--with the caveat that you still need to be aware of what's actually happening on the DB side to prevent what can be serious performance implications.
For complicated requirements, you'll learn to understand why they call ORMs the "Vietname of computer science"... "We have learned the lessons of Vietnam... do not go to Vietnam."
How to choose that which ORM would be feasible for a web Application? e.g if we are using Linq then why not nhibernate? and Which one is better and why
Every ORM that claims linq support, supports linq to a degree, however the completeness of the implementations vary greatly, sometimes because of the way the ORM is implemented, sometimes because of the quality of the Linq implementation.
Even the Linq implementations between Linq to Sql and Entity Framework v4 vary greatly, if you then look at NHibernate's or LlblGenPro's implementations you will find there are queries that are possible in sql that each doesn't support in the same way, if at all, or that the support with different levels of efficiency.
You really need to evaluate the particular ORM's Linq implementation against the type of data retrieval you tend/want to do.
I think a lot would depend on the application you are building.
On the other hand, NHibernate is very powerful and can be customized to do just about anything. We recently dumped our old ORM and moved to NHibernate because we just couldn't do what we needed to do without it.
You can use Linq with nHibernate. But take the most popular ORM. The one the most developers use.
It will be easier to find a developers to maintain and enhance the project and it will be easier to find solutions to your problems on Google.
I'm still using nHibernate but new versions of Entity Framework look promising.
I will switch when Entity Framework will become as powerful as nHibernate.