Win a copy of Escape Velocity: Better Metrics for Agile Teams this week in the Agile and Other Processes forum!

Ryan Breidenbach

author
+ Follow
since Jan 06, 2004
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ryan Breidenbach

You can use it as your ORM or it can work with other ORM like Hibernate.

Not to be picky, but... Spring does not have its own ORM framework. It provides a framework that makes it much easier to work with JDBC, as well as integration with several ORM tools, such as Hibernate, JDO, iBATIS and OJB.

You can use it as your ORM or it can work with other ORM like Hibernate. You can also use it in building your web layer and for your view layer as an alternative to Struts or you can use it to work with Struts.

Just to be clear, Spring does not provide its own view technology. It does integrate with other view technologies like JSP, Tapestry and Velocity. It also provides Spring tags for easier integration.
From your original code example, try this instead:



Spring's bean factory will not return an instance of a Bank, but rather a dynamically created object that implements the IBank interface that proxies method invocations to your a Bank object.
Ugg. Posted before I was finished...

As I was saying, all of the actual persistence of data will be done by Hibernate. What Spring adds is:

1. Ability to inject your Hibernate-enabled DAOs into your objects.

2. Helper classes that catch Hibernate exceptions and translate them into Spring's more generalized DaoAccessException hierarchy. This decouples the rest of your application from Hibernate.

3. Allows you to wire and configure your Hibernate classes in your Spring mapping file. The means configuring classes such as your SessionFactory as well as your DataSource.

These first three points are pretty straight forward. Hence, the brevity of the Hibernate coverage. The final piece to the puzzle is that using Hibernate with Spring allows you to use Spring's declarative transaction management. Chapter 5 is completely dedicated to this chapter.
The Spring + Hibernate piece of the book *is* pretty light for one main reason - there is not a whole lot to it. If you have used Hibernate at all, you know is a feature rich persistence framework.
It looks like you answered your own question, but just to add on...

Yes, we cover AOP. In fact, chapter 3 is dedicated to this topic. We also cover AOP as it pertains to declarative transaction management in depth in chapter 5.
Karthik,

Can you explain a little bit more what you are looking for. Are you talking about retrieving a PO from the database?
I always saw the "reducing the cost of programming to interfaces" benefit in a different light. As the OP said, programming to interfaces is a good thing - it helps create decoupled applications. However, these interface dependencies have to be resolved to a concrete class somehow.

It is this "somehow" that has always been the problem for me. For non-EJB applications, I would typically create a custom factory that my objects would query to obtain the appropriate implementation of a given interface. This meant two things:

1. I had to actively look up my dependencies. I don't really like this approach. To me, it cluters up my classes with dependency look-ups that aren't really relevant to the specific duting of that class (enforcing business rules, persisting data, etc). Instead, I have junk like:



Blech!

2. I had to figure out a way to configure my factory so it would know what the appropriate implementation class is for a given interface. Again, something I don't want to spend a lot of effort on - creating customizable factories.

Spring solves both of these issues. Its IoC approach elimates the need for active dependency resolution. Instead, my objects are *given* their dependant objects at run time. Cool!

More importantly, Spring already comes with a full-featured means to configure my "factory" - in this case the Spring container itself. No longer do I have to create custom factories, I just need to configure Spring with an XML file that is quite clear and intuitive.

In a nutshell, programming to interfaces *is* a good thing and Spring makes it easy to do this.

Originally posted by Pradeep Bhat:
Hello authors,

Do you suggest moving existing struts application to Spring framework?



I have done this before of a relatively small application and it is a lot of effort. I wouldn't recommend it unless you have a very compelling reason to do this - "I think Spring is cooler than Struts" is not compelling enough ;-)
There are many code examples throughout the book. Most chapters include both standalone code snippets as well as some code that is part of an example application that is developed through the entire book. We made our best effort to give examples that are not too trivial as to be useless, but are succinct enough to cut right to the point we are trying to make.

You can get a taste of the writing style of the book as well as the level of code examples from our sample chapters here:

http://www.manning-source.com/books/walls2/walls2_chp1.pdf
http://www.manning-source.com/books/walls2/walls2_chp7.pdf

Enjoy.
Adding on to what Craig said...

The Spring services you will be using, such as transaction support or Spring's MVC framework, scale just fine because they do not depend on any user state. The two areas of your application you need to look at regarding clustering are your web container and your persistence layer.

Your web container (Tomcat, Resin, WebSphere, etc) will be responsible for clustering the web layer. This typically means making the HttpSession object available to multiple server, either by multicasting the HttpSession state to multiple servers or persisting the HttpSession state in a database. Whatever the case, clustering your web layer will be a feature of your web container, not Spring.

As for your persistence layer (Hibernate, JDO, etc)... if you are going to need any caching of your persistence objects, your peristence solution should be clusterable if you want to scale across multiple servers. Again, this is a feature of your persistence solution, not Spring.

Hope this helps.
Before I reply, let me say that this is speculation on my part - I have never done any profiling with Spring (never had a reason to). That said...

I seriously doubt using Spring will have any impact on GC performance problems. First, in a typical application, most objects used by Spring will either be container objects internal to Spring or your application's "infrastructure" objects (DAOs, service objects, aspects, MVC support objects, etc). These will all most likely be singleton objects that will live for the lifetime of your application. In other words, GC friendly objects.

For those objects that are created ofter, these will either be your applications domain objects or Spring prototype beans. Either way, these will usually be cheap objects to create. Also, you *need* to create these objects as these are going to be stateful, usually short lived objects. This behavior will be the same for non-Spring applications as well.

Finally, any Spring object creation during the runtime of your application will probably be relatively small to the number of objects created by other parts of your application, such as your persistence layer or your web container.

So, I think it is a fair assumption that Spring will not add any significant GC overhead.
I just realized I pasted the wrong link to the Spring forums. Here is the correct link:

http://forum.springframework.org/

Originally posted by Reghu Ram T:
Hello ranchers,
I am interested in learning Spring. But i am constrained by the availability of time as i have a long list of other things on my learning list ( Web Services, J2ME so on.. ).
Are there any good resources available on the net where in i can get good overview of Spring. Any links and pointers would be helpful !



Gee, this is the easiest question so far. Just buy Spring in Action

Seriously, there are lots a great resources on the net for learning Spring:

- The official Spring docs are a great place to start: http://www.springframework.org/documentation.html
- Bruce Tate has written a couple of good articles on Spring here: http://www.oreillynet.com/articles/author/1794.-
- If you dig into Spring and have some questions, the Spring forums are really good as well: http://www.springframework.org/documentation.html

And not to me a complete shill, I really think Spring in Action is a good resource for learing Spring from the ground up. We spend quite a bit of time explaining the core concepts of Spring - Inversion of Control and AOP - so that even if these concepts are new to you, you will be able pick up Spring.

Good luck.

Originally posted by Pradeep Bhat:

Thanks a lot.

Does the Spring framework do any kind of object pooling like the EJB container? Thanks



Yes, Spring does provide a pooling capability through its AOP framework. In broad terms, you configure a ProxyBeanFactory in your application context. The "target" bean of the bean factory is actually a pool of beans (the size of which you can of course configure). Whenever a bean of this type is request from the application context, an instance of one of the pooled beans is returned. You can read the official Spring docs on this feature here:

http://www.springframework.org/docs/reference/aop.html#aop-ts-pool

We do not cover the pooling aspect of Spring's AOP in Spring in Action, and here is why. EJBs do offer pooling. You will use these EJBs in your business and persistence layers of your application. In your Spring application, you will likely be using POJOs to provide these same services (with some AOP thrown in to add features like transaction management). However, these objects will most likely be stateless and threadsade, so pooling is not necessary. You can simply creater singleton Spring beans.

The best pooling scenario we could come up with was connection pooling. This feature is already available through other means, so we opted to leave the pooling feature out of the book - to complex of a topic for too infrequent of a use case.