Hi, I have been reading about these 'Lightweight' frameworks. Please tell me what IS a lightweight framework? I have worked on Struts and as far as I know, frameworks are set of rules and guidelines on how to use existing components mixing a fair bit of Best-Practices and Design Patterns. How do you decide a framework is Lightweight or Heavyweight?
Do you mean lightweight "framework", or lightweight "container"?
Joined: Sep 08, 2004
Hi, Offcourse I meant Lightweight Frameworks. I found some information about the subject and one of the salient features of these frameworks is lesser dependence on Interfaces and Classes (like EJB 2.0 Spec.) and focus on using POJOs and reusability of components. Could you tell me something more on it.
Joined: Jul 28, 2003
I googled around a bit, but can't find a good definition for it, so unless someone can point us to one, I guess it means whatever an author or vendor wants it to mean.
It was interesting that, in my search results, no one ever spoke highly of "heavyweight frameworks", so I guess heavyweight is now "bad" and lightweight is now "good".
My understanding, from what I read in "Pro Spring" and "Professional Java Development with the Spring Framework", is that the term "lightweight" refers to the conceptual weight of a framework. Lightweight frameworks like Spring have minimal impact to an application. That is, it does not require as many code changes to incorporate them into your application as does the more heavyweight frameworks like EJB. When you create an EJB, you have to deal with several interfaces and it is pretty clear by looking at the code that an EJB is tightly coupled to the J2EE framework. On the other hand, a POJO is usually blissfully unaware that it is being used in the Spring Framework. Spring is minimally-invasive. There are also claims that it should not be a very difficult task to take Spring out and replace it with another similar framework.
With lightweight frameworks, you do not have to think too much about the underlying framework because there really isn't much code to write that explicitly ties you in with the "plumbing". On the other hand, traditional J2EE development with EJB entails writing a lot of "plumbing" code which weighs you down conceptually. [ May 25, 2006: Message edited by: Junilu Lacar ]
what you say seems to me very logical and correct. So I am asking you something that's sort of a case study in jumping to new technologies without understanding their use. I had worked in a project (with an IT company) which was developing an application using Struts framework and it was using EJB components also. So all the backend processing (database handling etc.) was being done by the EJBs. Now according to what you say, this seems to be the most wrong design because here we are nullifying the lightness of Struts Framework by using EJB. What do you say?
Originally posted by Abhishek Asthana: Now according to what you say, this seems to be the most wrong design because here we are nullifying the lightness of Struts Framework by using EJB.
The use of EJB in your project does not necessarily make the design wrong nor is it necessarily wrong to use EJB with Struts. These two technologies deal with different concerns and each can be used independently of the other. In fact, there is nothing inherently wrong with using Spring with EJBs either. What makes a design wrong--I prefer to use the term "a poor choice"--is when it is applied to a problem in the wrong context or when there is a simpler design that addresses the problem just as effectively.
If you want to see if EJBs are a good design choice, map your problem to those that EJBs are supposed to solve. My "acid test" for considering the use of EJBs is to ask the question "Do I need to manage distributed transactions--transactions that go across several machines/processes/JVMs?" If I can't answer yes to that question, I wouldn't use EJBs. [ May 26, 2006: Message edited by: Junilu Lacar ]
Joined: Jul 28, 2003
Well said, Junilu, and I'm thinking that part of what you said be a good definition of "lightweight":
<quote>a simpler design that addresses the problem just as effectively.</quote>