Why Spring

[spring04]

Our team is involved in redesigning a legacy system using the latest technologies. Facinated by the domain model and the open source projects, we decided that we will use JBoss/Hibernate/Eclipse/XDoclet/MySQL. Just few days before, i came to know about Spring. After going through some articles/documents, i was quite impressed by the features that Spring offers and wanted to use Spring with Hibernate. For the past two days, i'm trying to prototype an application to see the spring app working.

We are NOT developing a web application. I would greatly appreciate if some one could provide me some details of how our application WITH SPRING Will make a difference.

This would be really useful to convince my boss to use Spring in our project.

[kay]

Seeing as you'll be using Hibernate, here are some advantages of using Spring's DAO infrastructure instead of interfacing directly with Hibernate:

* Much better and cleverer exception handling
* Less boilerlpate code both inside DAOs and business objects if you use IoC
* Ability to do declarative transactions (no code) without the complexities of EJB
* Ability to mix in straight JDBC code (also through Spring DAO support) if you need to, and still participate in transactions, while being completely transparent to your service layer
* Coupled with Hibernate, almost complete database portability - it doesn't get better than this

Also, I'm sure you'll find plenty other useful bits in Spring even if you're not doing a web app. Good luck!

[katentim]

See my previous post

The Web infrastructure is only part of Spring, so I highly recommend you investigate it's other features. As well as those listed above you have AOP and IoC.

[twicet]

Like others have said about the other features, the other good thing is that configuration in Spring is consistent across all the other modules.

[spring04]

Thanks very much for all the responses.

We are planning to develop a OS X specific client and it's a stand-alone app. We've already decided NOT TO USE EJB. Hence, the choice is Hibernate. I'm very excited to know about Spring and i'm trying to learn it quickly and thoroughly.

As we add another framework/layer, how does Spring/Hibernate perform?

If you guys could share your experience, it would be great.

Thanks again.

[cyboc]

We are NOT developing a web application. We are planning to develop a OS X specific client and it's a stand-alone app.

So I assume that means you are making a (Java) rich client. Have you looked at Spring Rich Client (a subproject of Spring)? It's currently at the alpha stage but there are a LOT of useful features in it already. For instance, it can automatically bind Swing controls (e.g. JTextField) to fields in domain objects so that you don't have to manually write getText(), setText() code. Very cool.

We've already decided NOT TO USE EJB.

Good call!

I'm very excited to know about Spring and i'm trying to learn it quickly and thoroughly.

I highly recommend the book Expert One-on-One J2EE Development without EJB. Admittedly, it does cover some of the same topics as the free Spring Reference Documentation. However, it goes into more depth and answers a lot of the "why" questions.

As we add another framework/layer, how does Spring/Hibernate perform?

I'm currently starting to convert a legacy app to Spring/Hibernate. The legacy app uses Borland's (aging) DataExpress library for persistence. With the first use-case I converted, we noticed a 50% reduction in load times for a large object graph. Your mileague may vary but I think Spring/Hibernate performs very well so far.

Note that using the DAO pattern and Spring's various DAO support classes, you can easily use both Hibernate AND Spring's JDBC Abstraction layer in the same DAO implementation. Furthermore, it's very easy to configure that DAO so that both Hibernate and Spring JDBC can use the same underlying DB connection and transaction. We're using Hibernate for read-write use cases (especially ones involving inheritance relationships) and Spring JDBC for read-only use cases. If you don't like Spring JDBC, you can easily switch to IBATIS. Spring makes it easy to swap in and out various parts.

[spring04]

Thanks cyboc.

We are NOT planning to develop JAVA based client. It'll be an OS X based Cocoa framework to provide OS X look-and-feel.

I'm currently starting to convert a legacy app to Spring/Hibernate. The legacy app uses Borland's (aging) DataExpress library for persistence. With the first use-case I converted, we noticed a 50% reduction in load times for a large object graph. Your mileague may vary but I think Spring/Hibernate performs very well so far.

Note that using the DAO pattern and Spring's various DAO support classes, you can easily use both Hibernate AND Spring's JDBC Abstraction layer in the same DAO implementation. Furthermore, it's very easy to configure that DAO so that both Hibernate and Spring JDBC can use the same underlying DB connection and transaction. We're using Hibernate for read-write use cases (especially ones involving inheritance relationships) and Spring JDBC for read-only use cases. If you don't like Spring JDBC, you can easily switch to IBATIS. Spring makes it easy to swap in and out various parts.

I'm just curious why you choose to use JDBC for read-only use cases and Hibernate for read-write usecases. Any specific reason???

Our legacy system that we are redesigning is extensively using stored procedures and hence performs well. That's why i' concerned that by not using stored procedures and adding extra layers, how my new system is going to perform. I do know that Hibernate 3.0 supports stored procs but i'm trying to avoid stored procedures to make my DAL more portable on various DBMS.

Thanks!

[cyboc]

We are NOT planning to develop JAVA based client. It'll be an OS X based Cocoa framework to provide OS X look-and-feel.

I don't really know much about using Java in OS X. However, according to this article, "with a few simple tweaks you can give your Java application a native look and feel so that Mac OS X users can install and run your application without being aware that they are running a cross-platform application". I don't know if that is enough to change your mind but IMHO it would be easier to develop your app if use Java on both client and server. However, it you do want to use a non-Java client, Spring makes it possible and provides easy-to-use abstractions. For example, you could you JAX-RPC web services for non-java to java communications (see chapter 11 in "Expert One-on-One J2EE Development without EJB" for more details). Anyway, that's not my area of expertise so you I can't provide any detailed advice on this topic.

I'm just curious why you choose to use JDBC for read-only use cases and Hibernate for read-write usecases. Any specific reason???

First, it is important to note that I'm using JDBC abstractions like Spring JDBC and IBATIS Sql Maps, not raw JDBC. Raw JDBC is horrible to write, maintain and test.

Anyway, in my experience, JDBC abstractions usually perform faster than O/R mapping, especially for read-only use cases. However, the problem with using JDBC abstractions for read-write use cases is that it usually requires you to use very coarse grained DAO's and to write SQL update, delete and insert queries. With Hibernate, it is very easy to load an object, call a few setters and then save the changes. Also Hibernate is much simpler to use than JDBC abstraction when you a saving an object that is mapped to several relational tables via vertical mapping of an inheritance tree.

I've found that Hibernate is not always a one-size-fits-all solution, at least not for my requirements. First of all, at least the last time I checked, HIbernate doesn't really support the SQL UNION operator. Some people say that UNION is not OO but nevertheless it is handy at times especially with legacy database schemas. Furthermore, I think JDBC abstraction is faster (and perhaps more flexible and easier) for doing set-based updates and aggregate SQL operations.

Anyway, I highly recommend that you read chapter 10 in "Expert One-on-One J2EE Development without EJB". It answers a lot of questions like "when should you choose JDBC abstraction?" and "when should you choose O/R mapping?".

Also, I recommend that you search Spring's Data Access forum. There are several discussions there regarding implementing DAO's that combine Hibernate and JDBC.

Our legacy system that we are redesigning is extensively using stored procedures and hence performs well. That's why i' concerned that by not using stored procedures and adding extra layers, how my new system is going to perform. I do know that Hibernate 3.0 supports stored procs but i'm trying to avoid stored procedures to make my DAL more portable on various DBMS.

I wouldn't reject stored procedures a priori. As Rod says, architects are often overly concerned with portability and performance can suffer greatly as a result. I think its okay to use stored procs as long as you hide the non-portable code behind a portable interface. To aid you with this, Spring's JDBC abstraction provides the RdbmsOperation class hierarchy which includes the StoredProcedure class. The StoredProcedure class "models a stored procedure as a thread-safe RDBMS operation object with a single stateless method, hiding database-specific syntax and the name of the stored procedure. A stored procedure object can even implement a single-method interface, completely removing the dependency of code using it on the use of a stored procedure".

Also ask yourself, what is the possibility that you will actually change to a different DBMS? Recall XP's mantra of YAGNI...

Hehe, I wonder if Rod will add anything to this answer. How can you tell I have read his books...

[spring04]

Thanks cyboc for a detailed response.

On OS X, Cocoa framework performs poorly if we use Java. We are not planning to write a SWING based app as we don't have expertise on that Otherwise we've nothing against JAVA based clients.

I'm new to Spring and i don't know much about JDBC Abstractions. Thanks for pointing this out. I'll go through the documentation for this and try to understand it better. (including RDBMOpertaions that you mentioned)

Our application has large number of DB tables and associations. I'm sure performance is very important . I'll definitely keep the option of using Stored Procedures in a portable way by isolating that code as required.

After all, no matter how good and layered is your architecture, all that matters is the performance.

Regarding the DB options, as of now we are planning to use Oracle but there is a good possibility that we will migrate to MySQL in the future and remember, MySQL has no stored procedures.


Thanks!

[steve_smith]

Hehe, I wonder if Rod will add anything to this answer. How can you tell I have read his books

I'm reading now his book and from you response I think you must have memorize it! Or maybe you are Rod? :P