This question already has answers here:
Places where JavaBeans are used?
(4 answers)
Closed 9 years ago.
I am new in j2ee and want to know about java beans. I have one java class, and use an instance of that class in another class. What are the reasons I should define the first class as a java bean and then inject an instance of that in another class? what are the advantages of that? What kind of classes are better to be defined as java beans? For example, I may have a pojo to be used in ORMapping, a class to make UI (I use vaadin to make UI) , another class to do business logic (for example, calculate the result specific mathematical formula) , and another class to do DB operations. Which one is the candidate to be defined as a java bean, using ejb or spring?
The JavaBeans designation only concerns the convention of providing accessor methods for the public properties of the class. POJO is an orthogonal concept and a Java bean may easily also be a POJO.
You seem to be contemplating beans in the context of the Spring IoC container. Spring uses the term "bean" in quite a loose sense and the actual objects may not even comply with the JavaBeans specification. Most typically they provide only a setter (no getter).
Now, the advantages of letting an IoC container wire together interdependent objects are many and this practice is warmly recommended. Some points:
the concern of bean instantiation is centralized;
less coupling between beans: the client bean doesn't need to know how to initialize its collaborators;
trivially easy handling of the otherwise massive problem of circular dependencies;
no boilerplate code involving instantiation sprinkled around code;
easy reuse of singletons => saves memory, brings order and consistency to the object system;
declarative control of bean lifecycle, again with no boilerplate code in the beans themselves.
From the javadocs:
JavaBeans™ makes it easy to reuse software components. Developers can
use software components written by others without having to understand
their inner workings.
To understand why software components are useful, think of a worker
assembling a car. Instead of building a radio from scratch, for
example, she simply obtains a radio and hooks it up with the rest of
the car.
Java beans is used to store data persistently in database. this class consist of setter and getter method. you need to create another java class to do this operation
Related
I just started getting into DI(dependency injection) frameworks and I was wondering should I inject every and any class or specific classes? How would I know which classes you should inject and which you shouldn't?
A lot of the tutorials(Dagger 2, Hilt, etc) that I've found don't seem to talk about this or don't explain it very well.
I don't have any code examples cause I'm trying out things as I read along with tutorials. Just trying to get a feeling of things.
Explain it as if I was 4 year old :)
My answer is no, you do not have to do that use dependency injection every time you need to create an object.
This is the intent of dependency injection according to Wikipedia
The intent behind dependency injection is to achieve separation of concerns of construction and use of objects. This can increase readability and code reuse.
So you should use dependency injection it would improve your code reuse and readability.
This article mentions some cases where you should use dependency injection to create objects
You need to inject configuration data into one or more components.
You need to inject the same dependency into multiple components.
You need to inject different implementations of the same dependency.
You need to inject the same implementation in different configurations.
You need some of the services provided by the container.
Imagine that you have username and password fields in an app that you would use to capture a user's detail, you do not have to use dependency injection to create a User object from the details, you can just create it directly, its not something that would be reused across your application, there are other object creation patterns that you should look into like factory pattern, abstract factory pattern, builder pattern e.t.c.
There's a certain number of classes which I always inject and never ask myself the question: the application context, shared preferences, DAOs, Retrofit, Json object. As you can see, these are usually related the third-party libraries or the Android framework.
Then there are classes which depend on those: the repository is a common example, but there are many more. For example you could have a preference manager which depends on shared preferences and context. Or you could have a class JsonExporter used to export user data which depends on DAOs and the Json mapper.
In turn, there are other classes which depend on those new classes: a view model/presenter in MVVM/MVP architecture could depend on both the repository and JsonExporter for example. At this point you have two choices:
Instantiate the class yourself. But that means you need to have access to all of the class' dependencies, which are only available through dependency injection...
so you might as well inject it. The cost of injection at this point is often very low, just adding #Inject to the constructor. Only the base dependencies have to be provided in a module.
From a certain number of injected base classes, the decision to inject those more nested in the dependency graph really comes automatically.
There are also cases where you'll have a class that depends on nothing. Perhaps you decided to extract code from a big class into another one. Or perhaps the class just has no dependencies. I probably wouldn't inject such a class, there's no point.
Singletons are often handy to inject because the dependency injection framework (e.g. Dagger) can make sure there's always only one instance automatically.
One reason why we do dependency injection is so that classes depend on abstractions, not concretions (aka inversion of control). It's useful to have your class depend on a Repository interface, because you can decide to provide it with the implementation you want, for example RealRepository in the app, and MockRepository in tests. Another example is flavors or build variants: an injected FlavorBehavior interface could have different implementations in two different flavors. It's not the class' responsability to decide which to use.
Note that this is not a definitive answer, and I'm not an expert on the subject. It's an opinion-based subject too.
Example:
class MyClass<S> {
}
Is the above class a POJO?
EDIT: The question has been put on hold so let me explain further. Firstly, the question is very clear and precise. Secondly, I think it is important since numerous docs says things like (to quote the google docs at https://developers.google.com/eclipse/docs/endpoints-addentities):
In the Endpoint methods, the return value type cannot be simple type such as String or int. The return value needs to be a POJO, an array or a Collection.
In such a case I would want to know exactly what classes I can use without having to go through a tedious trial-and-error process.
The term POJO (plain old java object) became popular around the time of early version of J2EE (now called JEE) and Enterprise Java Beans (EJB).
EJB sought to extend the java-beans philosophy of reusable, component driven architectures by providing enterprise service abstractions - things like database access, security, messaging.
Unfortunately, these early attempts required extending base classes that could only be used within the context of an application server. This had a lot of problems, for example it made testing a very cumbersome and slow process.
As a counterpoint to this POJOs emerged which aimed to provide enterprise services without having to extend base classes. Spring used Dependency Injection and Aspect Oriented Programming for this, and quickly became popular as classes could now easily be unit and integration tested outside of the heavy app server.
The idea behind POJO is that your class should extend from the business domain rather than an infrastructure domain. Therefore yes, there's no reason why a POJO can't use generics, as long as it honors this philosophy.
Every Java Class which doesnt extend prespecified classes and doesnt implement prespecified Interfaces. Also a POJO (Plain Old Java Object) doesnt have a prespecified Annotation.
This means your example is a POJO.
I am re-factoring a legacy Java application to use Spring.
This involves declaring the application classes as Spring beans and then replacing all occurrences of new with context.getBean OR with DI.
I'm re-writing application logic in way that some classes become singletons. However since they are being instantiated using new in other locations, multiple copies would exist which would mess up the business logic.
I'd like to ensure that application explicitly fails whenever it tries to instantiate an object by itself, instead of running and misbehaving in unpredictable ways. (I'm not sure that the re-factoring has covered 100% of the application there still might be new lurked up in some corner)
What is the best way of ensuring that a class can only be instantiated by Spring container?
(I'm hoping to avoid writing a factory for each class)
As from your question
In this particular scenario only one copy of an object should exist which is fetched from the context, multiple copies would mess up the business logic.
you can create classic singleton and use getInstance() method as factory method in bean definition in spring's xml file:
<bean id="myBean" class="MyClass" factory-method="getInstance"/>
Make your constructor private, and than no one can call it. Additionally you will see errors in compile time, if some parts of old code uses new to instantiate your class.
So, yeah. That. I'm going through the tutorial one step at a time, so if the answer comes up later, forgive me. It's step 1 in this section.
I understand the ease of using this to have access in other methods in the EntryPoint class, but coming from the Spring MVC world, this sort of thing might be thought of as a controller and be a singleton (bean). Is it wrong to think this way in the GWT world?
With GWT you are coding as if it was a desktop AWT program. So, you do not have CDI or anything similar.
So, if you put all your information in a bean, you still would have to either:
keep a bean attribute in the class
pass it as a parameter in the method call
to get a reference to it (instead of retrieving it from CDI when needed)
While you can still use a bean when needed, these attributes are closely linked to the main class (in fact they are other graphical components to show). In general, I would only use bean when you have a bunch of attributes that are tightly coupled between them but are not tightly coupled to any other class.
I am taking a look into Spring as a web framework, however I am needing a bit of help getting my head around DI.
The concept of objects getting constructed in the container on run time is such a new concept.
I am just wondering how this will reflect in a big application, would I have some modules doing work that are more highly coupled or should every object be initialised at runtime?
It all seems a little intensive to me, I mean say for example I have a CSV file data mining application that removes the data per row - each rows data is encapsulated in one of my own CSVRow objects for processing or whatever. These objects are instantiated whenever an Excel file maybe uploaded to the server. I don't know how many I will need to create?
I seem to be getting a bit lost, any clarity, an overview or some guidance would be much appreciated.
Thanks in advance!
I'll try to put it simply:
use dependency injection for stateless classes that have logic (business logic, persistence logic, front-end logic)
use new for value objects
Broadly speaking, an application is made up of a collection of classes that implement the business logic.
Normally each object is responsible to obtain references of the objects it needs (and this object's dependencies).
I think it is obvious that this leads to:
1) tightly coupled classes
2) code hard to test since each object instantiates specific classes it depends on and if there needs to be a change, the code must be modified.
So using Dependency Injections the objects do not instantiate the dependent objects themselves but an "external component" provides the dependencies at the object creation time i.e. injects the dependencies into the objects.
So in your example, the idea is that you can have for example a CsvRow object instantiated by Spring (along with all its dependencies) and get an object whenever needed. It is also possible to switch to for example CsvRow2 object (another implementation) by just changing your configuration
You don't need to use DI for your CSV row abstraction. Once you get the file, when you start parsing it, your code can create the CSVRow things as it goes. You don't need to wire them up.
You certainly could if you wanted to. You would grab your applicationContext and just get the beans by name. You would want to do this if the CsvRow had dependencies that you wanted Spring to manage for you.
I think of Spring as a way to create "singletons". When I want to guarantee there's only one instance of a class in the application, use Spring to create it. But, instead of being a traditional singleton with a static INSTANCE field or similar, it's a POJO with whatever constructors / setters you need. Spring creates the instance at runtime for you and makes sure that creation only happens once.