These days I used to work with JSF, but there's a "convention" I'm in doubt if I should use. While working with managed beans, people used to name it as XxxxxManagedBean where the prefix can be any name related to your business.
Have you worked like that? Particularly, I don't like that much despite makes search easy. Are you using another convention?
Thanks for answering this simple doubt.
There is no strict convention specified by JSF itself. I've seen the following conventions:
FooBean
FooBacking
FooManager
FooController
FooManagedBean
Or even just Foo which is then placed in a specific package like com.example.controller, com.example.backing or even com.example.view, etc.
I myself tend to use FooManager for application and session scoped beans (e.g. DataManager, UserManager, LocaleManager, etc) and just Foo, or as mandated by my current project, FooBacking (e.g. Login or LoginBacking) for request and view scoped beans, which are each usually tied to a specific <h:form> and/or view.
FooBean is too vague. Really a lot of classes can be marked as javabeans. JSF managed beans, JPA entities, EJBs, data transfer objects, value objects, etc. The Bean naming does not indicate the real responsibility of the class in any way. True, I use often public class Bean or MyBean in my generic code examples in blogs or forum/Q&A answers, but in real world you should avoid that.
FooManagedBean is IMO a poor name, it's not only too long and ugly, but technically, a managed bean is an instance of a backing bean which is managed by some framework (JSF in this case). The class definition itself is really a backing bean, not a managed bean. So a FooBackingBean is technically more correct, but it's still too long and the Bean part is a bit itchy.
Anyway, this is a pretty subjective question which can hardly be answered objectively with The One And Correct answer. It really doesn't matter that much to me or anyone else what you makes of it, as long as you're consistent with it throughout the entire project.
Related
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.
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
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.
Yes, I searched for questions about backing beans and I found many questions. I read them, and I get some parts of it but I need to ask another question, sorry.
After what I understand backing beans are needed because of JSF MVC pattern. Backing beans are the model. So if you have a page that displays a form, an image and a login box the backing beans will have getter/setter pairs for the data that needs to be exposed or changed in the view. And the backing beans will also have methods related to this such as what happen when you submit the form, login in etc.
So my question is if the statements above is correct, and the number of backing beans you make for the components above is dependent on how much code it is?
Would one backing bean exposing methods and getter/setter pairs for all components on this page be legal and "correct" (meaning that I don't do any wrong) in the same way as making 3 backing beans; one for each component would also be fine.
Does it all boil down to experience to see when you should separate vs. making one backing bean for each page, and also the logical part of it? I heard one guy made a backing bean for each component on the page but it sounds like you end up with a lot of small classes.
I would highly apprciate if somebody could verify and correct me.
It is legal for all components in a view to be bound to one managed bean for properties and actions. IDE tooling may encourage you to do this with a single backing bean.
From a class point of view however this approach lacks granularity and can make the managed beans difficult to test. If a class doesn't have a clearly defined purpose then it can be difficult to assert they are doing that job. See warning sign "Summing up what the class does includes the word “and”". All versions of JSF support dependency injection so it is relatively easy to rely on composition to assemble your managed beans.
This is a somewhat subjective topic and the answer depends on other factors (application scale; view design; page function.)
Studying JSR-299, I read section 5.1 of the Weld reference which explains how scopes work in CDI. Apparently, context is a concept closely related to scope. The difference is not clear in my mind and I feel tempted to even use the words interchangeably.
What is the difference between scope and context? What is the relationship between the two concepts?
Each scope has a separate context.
The context is a container for beans which have been defined with the respective scope.
That's why context implementations carry the name of the scope - ApplicationContext, DependentContext, RequestContext, etc.
This is an implementation detail actually - as a user of CDI you should only know about scopes (because you define it for your beans), and the implementation decides where to place those beans and how to manage their lifecycle.
My understanding is that scope refers to where an object may be accessed from, while context enumerates the objects that can be accessed from some particular point in program execution. (That is, we talk about the scope of an object, and the context at some particular point in program execution.)
Mathematically speaking, both describe the can-access relation, but look at it in different directions.
First, we have concepts in our heads like applications, sessions, requests. Let's use the session concept in the following examples.
If we consider that a piece of execution is serving for a particular session, we'll say the session is part of the context of the execution; or, it is the session context of the execution.
A session has some variables, e.g. userName; we'll say the session is the scope of these variables.
Since both are pointing to the same session, it can get confusing. For example,
get the userName from the session context
get the userName from the session scope
both sound fine, because we are talking about an execution on a variable.
The following example is intelligible per the definition of scope
the scope of the injected bean is Session
but we don't have problem understanding what's really going on. If we want to, we can expand it till it's based on basic usages of words; we don't do that because it will be very verbose.
An author faces the difficult task of packing the words succinctly yet expecting readers somehow understand the complex meaning. Texts about context and scope usually appear to be gibberish to those who haven't understood the concepts.
API names are even more difficult to come up with, because codes are not English sentences. Context or Scope are pretty much interchangeable. If there's only one object representing a session, the class probably should be named just Session. If we split the part about variable manipulation, that part can be called SessionScope. However, the meaning of SessionContext is too elusive, the best we can tell, from the name alone, is that it is about something of a session - "context" here is pretty much an expletive.