IOC Frameworks

Hey guys, It's been a while since I've been around,

I've been actively doing development on enterprise level applications and was busy finishing my degree.

I'm curious as to your thoughts on different IOC frameworks, which you enjoy, and when you warrant the use of them (size of the project, do you use them when you need something to be very de-coupled where you can swap in and out (or request a different implementation at runtime)).

I've been playing with Tapestry-IOC and am loving it a lot, very easy to configure, to get up and running, and it is promoting very good development practices by requiring that most of your controls are written in terms of interfaces.

How does this compare to the Spring framework, or any other IOC you have used? I liked the fact that I did not need any XML configurations to get Tapestry up and running. A few simple annotations and it took care of the rest based on JNDI I believe.

Cheers,
Deliverance

Tapestry and Wicket are very nice in the fact that you are writing Java code and not worrying about XML configuration files (Spring, Struts ect.) and JSPs. You get to spend more time writing Java code and less time trying to configure your JSPs.

Personally, I think that Struts and Spring suck. I don't like having a million XML config files. When you have major changes you have to do it in 4-5 different **** places!! Hell, even a simple change such as changing a column name will force you to change it AT THE LEAST in the hibernate entity, hibernate DAO, Struts form class and the JSP (and everywhere you use it, i.e. any action classes or utility classes).

I don't like the fact that you cannot use your entity beans as your form beans. Why do I need two different classes that look almost exactly the same? Well, with Tapestry, Grails and JSF you don't have to worry about that. With Struts you have to define your Hibernate entity bean, then your Hibernate DAO class, then your form bean, then your action class, then your JSP, then your struts-config.xml entry, then your tiles.def (if using this, which actually makes itempleting easier). MUCH easier to do things Tapestry or Wicket in my opinion.

My next project for work here will probably be using FLEX with JSF as the back end. We sat around and discussed using Spring MVC and Tapestry, but in the end FLEX gives you the best customer presentation and it is very, well, flexible and easy to use. As for JSF, well, I know a lot of people don't like it, but it's part of Java and in the end it's really not all that bad.

By FLEX do you mean Adobe Flex as the presentation layer of your next web project?

If you use BlazeDS (or Adobe LifeCycle) there is very nice interaction between a Java container and a flash application through various streaming channels.

BTW, this is what I really enjoy about using Tapestry. I can focus on writing my code, I've only had to expose WS's, which is a breeze when deploying to Sun App Server as all the generation is taken care of for me, I just need to specify a few annotations on my web methods.

Now with Hibernate, maybe I am missing something, and still have more to learn, but with my experience I have just created DAO objects which give me a mapping to my database schema (unfortunately I have had to model my code around an existing DB) and I just use Transformers to convert to my DAO objects, after which I will still have to take care of manually persisting my code (I wrote myself a few helper classes which conditionally update a table with only non-null values in my corresponding DAO).

When using beans with Hibernate, is the persistence completely abstracted out?

Yes, we will be using Adobe FLEX for the presentation layer. I have never used BlazeDS before, how does it compare?

I completely agree, getting away from config files and JSP pages and getting back to writing Java code is so nice :). It's about time Java introduced a descent annotation system :rolleyes:.

Ok, with Hibernate you can create on the fly entries in a DAO class, but the recommended way is to use beans. Take the following example:

Say you have a ticket system. You have normalized the database to have a Ticket table, a TicketHistory table, a Users table and maybe a Documents table (for attaching documents to the tickets). Each table should have its own Entity bean.

These beans contain all of the fields (columns) for each table. This makes it easier to deal with. You will have a Ticket.java entity bean that holds all of the fields and annotations and a TicketDAO.java that holds all of your getAllTickets(), findById(long id) methods... and so on.

Using Hibernate in this way allows you to simply write code like this:

Code:

---

        Ticket ticket = null;
        try {
            Session session = HibernateUtil.getSession();
            ticket=session.load(Ticket.class, ticketId);
           
        }  catch (HibernateException ex) {
            throw new InfrastructureException(ex);
        }
        return ticket;

---

You have to, of course, set up the Hibernate mappings in our favorite format, XML, but that really isn't that difficult.

Now, that being said, if you use Tapestry, or one of the many newer frameworks, you can use that same entity bean as your Form object that gets passed around in session instead of having to use some apache BeanUtil class that performs a BeanToForm operation. Tapestry allows you to use the same class as oposed to Struts, this is why you are probably confused because you are using Tapestry and don't have the redundant bean classes. Which is the beauty of Tapestry.

The way I listed to use Hibernate above is the painstaking way that you have to use it in frameworks like Struts. So, in Struts you would need:

hibernate/entity/Ticket.java
hibernate/dao/TicketDAO.java
struts/form/Ticket.java
struts/action/CreateTicket.java

Both Ticket.java classes are almost identical. The getters, setters and class variables are exactly the same.

Well BlazeDS is a very nice bridge between Flex applications and Java. It's a framework which will let you do RPC calls (Async if you do a long-polling or use a real time streaming protocol, or synchronous).

It's all done over HTTP, where your clients subscribe to a Topic. You write your Java adapter more or less like you would configure a servlet, then expose an interface that flash can invoke. There's a tool called Gas3 (graniteds.org), maven plugin available, which will generate you ActionScript classes from your Java pojos, allowing you to marshall these objects across the stream you want to use. The only limitation with Gas3 is that it does not support enumerations yet, but it's nice to deal with objects when you're passing them around.

I haven't tested it with a tunneled connection, but I'm sure it's possible as well.