views:

624

answers:

4

Hi, I am developing a IT Monitoring Dashboard for the company I work at. The system will primarily perform monitoring of files, databases and servers. There will be a small part of the system which will allow the users to configure static data about the system eg: file locations, server names etc...

So as the app. will be a dashboard a lot of the application will consist of publishing data to the flex client to update all the monitoring views. So there will be limited database activity ie: insert/update/deletes.

I'm currently using a Spring/JDBC combination in the backend Java code. I have recently thought about moving to Hibernate for the ease of use in terms of CRUD operations (compared to Spring/JDBC).

Does anyone have any ideas on this? For what I am doing is Spring/JDBC enough? Is Spring/JDBC scalable? I'm looking more into the future if the Dashboard grows in terms of users (scalability) and in terms of functionality (more database operations).

PS: I haven't used hibernate before but have used JDO/Kodo and Toplink which funamentally work the same way to hibernate.

Thanks Mike

A: 

Hi Mike,

I am guessing you have looked at the remote class feature of blaze ds along with the pub/sub functionality. This effectively allows you to map a Java class to an action script class which can then be sent over the wire.

If you already have a defined entity model on the server which you can utilize it would be easy to integrate hibernate or similar technology as it would work at the entity/domain level.

You could take a top down approach and use hibernate to generate your schema for you from your annotated entity model. I am not familiar with spring/jdbc but hibernate can drastically simplify things even for simple apps.

In terms of scalability hibernate should not be an issue as it has many advanced features such as second level / distributed caching.

If your interested in learning how to generate JPA/hibernate mappings from an class take a look at the netbeans tutorials.

Karl
A: 

If you've used Kodo/JDO then DataNucleus should be simple for you. Depends on the complexity of object graphs whether it would be necessary to go to such a solution as against JDBC; you don't give an idea of the relation complexity of data. With DataNucleus you have a L2 cache just like with Kodo, providing much assistance in scalability.

--Andy (DataNucleus)

DataNucleus
+1  A: 

I would go with Hibernate for all of the aforementioned reasons, and use the DTO pattern for communicating between Java and Flex. You probably don't want to be sending your Hibernate domain objects directly over the wire.

Mike Sickler
+1  A: 

The key difference between Hibernate (and most other ORMs) versus Spring/JDBC is that most ORM's support "lazy loading" which can actually be very problematic in remoting applications. Suppose you are using Hibernate and have a Person class which has a collection of Address objects. If you ask Hibernate for a Person instance, by default it will load only the simple properties of Person and the "addresses" collection will be an empty proxy. When you access "addresses" for the first time, Hibernate will execute some SQL to magically "lazy load" the data into the addresses collection for you. When you pass Person with the lazy addresses up to whichever serializer in use, it will walk the entire object graph and trigger lazy loading of every lazy proxy it can reach. In a complex object model, this can result in literally thousands of SQL queries to fully load the object graph before sending it to the server, to say nothing of the multiple megabytes of data that will be send over the wire.

One of the other posters mentioned using DTO's with Hibernate and this is not a bad recommendation because it helps work around this lazy loading issue. You essentially wrap all of your entities with the DTO's and then return only DTO's to the serializer. Expanding the previous example, suppose Person also has a single Department object tied to it. PersonDto can instead have a "departmentId" property, which when accessed pulls only the "id" property from the underlying Department object. Since Hibernate lazy entity proxies are always populated with their identifier, you can can access this data without having to lazy load the object. Since PersonDto doesn't actually expose a Department object to the serializer, it will not be able to walk it and try to load all of the data.

There is one alternative to using DTO's with Hibernate, which is to do some very fancy things to those Hibernate lazy proxies so they play nicely with the serializer. Take a look at a project called Gilead if you want to learn more.

You also mentioned scalability and of course the answer is "it depends." :) In terms of handling more users, it will be easier to tune the SQL using Spring/JDBC which may increase performance and lessen load on the database, possibly allowing you to support more users. However, in terms of code maintainability and the sheer amount of work you'll need to do, Hibernate may offer a better option since it automates a lot of tedious crud functionality.

cliff.meyers