Struts is used for building a Presentation layer of an application. That is all.
Business and/or domain logic should be built separately in another layer, let's call it the Business layer.
Hibernate is a framework for coding the persistence part of an application, let's call this the Integration layer.
So, as you should see, Struts code and Hibernate code should never exist in the same class and should never be integrated.
You might find some examples in some books showing you how they might work together, but this is still bad form and should be looked at as only theory (and extra material the author wanted to include). Coding persistence along with presentation in one layer violates the Model View Controller principles [ July 04, 2008: Message edited by: James Clark ]
Hi i agree with what you say but i have seen alot of examples where the hiberante code is ritten in the Action class file. Apart from violating the design pattern there is nothing fundamently wrong with this,
Joined: Apr 16, 2008
Apart from violating the design pattern there is nothing fundamently wrong with this,
Yes. However, what does violating the design pattern mean to the state of the application and how difficult it will be to adapt to new technologies and API.
Speaking only in academic and theory terms, this is no big deal. But, in commercial settings where you have serious money at stake and a need to be agile, this matters a lot. And violating the pattern means a lot.
For example, say you write an application with 247 Struts Action sub-classes that deal with persistent objects and contain Hibernate persistence logic mixed in with the processing and business logic.
Two years pass.
Your competitor comes out with a new product with a series of fancy Ajax/Flash/WAP interfaces for web browsers, cell phones and the new biometric eye plug GUI.
You now have 400 Struts Action sub-classes in your application.
How much time will it take you to develop a new interface for your application using Java Server Faces?
How much will violating the MVC design pattern cost your company?
Hibernate code should not be in Struts Action sub-classes. The examples you see are bad examples, but they are just examples. Examples in books/web pages and code in the real business world are two different things. [ July 09, 2008: Message edited by: James Clark ]
I agree wholeheartedly with James' point that controller logic (a Struts Action) should be separated from model logic (Hibernate specific database code). I believe that any specific references to Hibernate do not belong in an Action class, but in the Hibernate POJOS themselves or in a DAO (Data Access Object) class.
However, there are issues when using Hibernate in a Struts project that need to be addressed such as how to manage the transaction boundaries and how to deal with Hibernate's "lazy fetch". To say that it is somehow bad form even to discuss how to make Struts and Hibernate work together is carrying it a bit too far.
To even call something a "Struts" project is misleading, I think. Struts is a only framework for building the web/interface component of a business/domain application, that should ideally be built with only POJO or EJB objects.
Presentation - Struts
Business - POJO or EJB
Integration - Hibernate, Relational Database, EIS, Web Services
To apply MVC to the above, Struts is used to write the Controller and the View. That is it. That is all. The Model is written with POJO or EJB. Hibernate code should not be mixed with business logic either.
Hibernate is way at the bottom.
Struts is way at the top.
To integrate them, or even think about integrating them does not make sense, I feel.
To say that it is somehow bad form even to discuss how to make Struts and Hibernate work together is carrying it a bit too far.
Good point. Thank you for pointing it out. [ July 09, 2008: Message edited by: James Clark ]