All the examples I've seen so far integrating spring/mvc with JSF uses DAO class, DAOImp, Service, ServiceImp and then JSF ManagedBean and as far as I know with EJB 3.1 all I need is EJB and JSF ManagedBean. I am not mentioning entities. So based on my understanding with Spring + JSF I need:
5 classes and with EJB + JSF I need only two classes. Please correct me if am wrong but if am right then what's the advantage of using spring with JSF.
Thanks.
You are wrong. -- You can skipp the DAO, DAOImpl and ServiceImpl if you want to implment all in the Service Class.
But even in EJB it is best practice to seperate the Service and the DAOs.
The usage of Interfaces is a kind of style. If you use interfaces, at least you can skip them to and create your services (and Dao) like EJB 3.1 interface free Beans (I don't know the correct name at the moment). At least there are the same pro and cons to use interfaces in Spring and EJB 3.1.
Summary: You can build Spring JSF2 Apps with 2 classes to, but it is best practice to seperate at least JSP (view), Service (EJB's) and DAOs.
comment by Spring or JSF: Ralph please give me an example, suppose I've an entity: Person with id, firstName and lastName what would be the code I need from spring aspect?
In traditonal Spring architecure you have the:
Person (Entity) Class -- the one with the #Entity
PersonDao - Interface that provides data base Load, Strore, Delete and Find Methods for the Person
PersonDaoImpl - implementation of the PersonDao Interface - (#Repository)
PersonService - Interface that provides business functionality arround the person, for example a create method that send an email after a person is created
PersonServiceImpl - Implementation of the PersonService Interface - it uses for example the PersonDao and other Sevices to provides its functionality (#Service)
PersonJSF-Managed Bean - handles the JSF stuff but has no business functionality, it uses the PersonService (or an other Service) to start business functionality
This is one of the most common architecural style (not only in Spring). But even for this there are some variants:
how DAO's can be invoked? All Dao Functions must be invoked via the according Service -- or direct
DAOs with or whithout Interfaces? (may you need the Interfaces for your Test Mock Framework?) -- (have a look at Hades, there is only the Interface, but in most cases no Impl)
Services with or whithout Interfaces? (
...
BTW: one other very intresting architural style, is the one hat Spring ROO uses: It has only the View (PersonController) and the Model (Person), and all DAO and Service Functionality is put in the Model class. -- That is a bit of real OO Design.
Related
I am trying to implement a Spring Boot REST API but I was asked to use a interface as dependency but no impl, and I don't know how to achieve this. The way I implemented was to have service classes for my entities and there I would just call the repository in my methods. I would like an example of implementation like this.
I watched some youtube tutorials but they all used impl classes
Your controller should have a field of your interface type, with the injecting annotation (in spring it's #Autowired). The DI framework will do the heavy-lifting on startup and inject the correct implementation at runtime
#Controller
public class MyController {
#Autowired
private MyInterface myInterface;
....
}
For this to work, your framework needs to recognize the concrete class. In spring you can achieve this in multiple ways - scanning package paths, xml configuration files and more.
Check the spring documentation to see which way suits you best
I have a spring-boot project. Some of the classes I am using it in the 'spring' way, meaning that they are annotated by "#Service", "#Repository", "#Autowired". At the same time, I have lots of classes, which are only used in the normal Java way, meaning that there are no any Spring annotations, and they are created in the standard way of constructing an object in a constructor.
For example, one of the non-annotated classes is:
public class GenericTree<T>
{
private GenericTreeNode<T> root;
public GenericTree ()
{
root = null;
}
public GenericTreeNode<T> getRoot ()
{
return this.root;
}
public void setRoot (GenericTreeNode<T> root)
{
this.root = root;
}
...
}
Is it OK or normal to have a mixure of classes with or without Spring annotations? Probably, I could convert all non-annotated classes into annotated classes by using Spring's annotation markers. Does that really benefit or is it necessary?
BTW, my application's main logic and functions are not web-centric, although they are created as a Spring project. The reason I created in Spring is I want to provide a restful service for my interface so that I can easily test in browser in development, and others can use it with Restful service.
Yes it is ok.
Keep in mind that annotations are not Spring exclusive. Annotations were introduced in Java 5 and they are just meta data for your Java code. This meta data can be useful at:
Compile time
Build time
Runtime
You can even create your own custom annotations and annotate your code with them.
Spring framework comes with some annotations and each one of them has its purpose, but that doesn't mean you have to annotate all your classes with Spring annotations when you are using this framework.
When you annotate your classes as Spring Beans, they become part of the Spring Application Context, thus making them available to be injected with the #Autowired annotation (Spring framework is based on the dependency injection design pattern). But Spring annotations have other implications too, I cannot go into the detail of each one of them but for example, you have to consider that the default scope of annotations like #Bean, #Component, #Controller, #Repository, #Service is Singleton. So whenever you annotate a class with one of these annotations and you don't define a scope, what you get is a singleton class shared all over your application. Other scopes are:
singleton
prototype
request
session
application
websocket
Taking in consideration your GenericTree class, does it make sense to annotate an abstract data structure class as a Spring Bean? Probably not.
So yes, when you develop an application based on Spring framework the normal thing is to have a mixture of Spring annotated classes and regular POJO's.
I recommend you to read the Spring framework documentation, learn what dependency injection is and the purpose and implications of the most used Spring annotations.
Last year when I started learning spring I remember an article that expalined that not all pojos are to be defined as beans. So I'm planning to create a web app say EmployeeMaintenance. CRUD Functionalities are there. I will surely end up creating pojos like Employee , EmployeeSupplementaryDetails, Address etc. Should I makes these beans and configure them in xml or annotate whatever. I'm sure my understanding of bean is not enough. I know that Dbconn , services etc should definitely be declared as bean.
All I need is what are the parameters I should consider before I make a pojo a Spring Bean.
General rule for making Java class a Spring bean is to ask yourself if you need to inject object into some other object or if you want the object to be managed by Spring components. The classes you listed as example doesn't seem to be good candidates for being Spring beans - they represent model data and will be passed as some service's methods parameters.
Examples of typical CRUD application beans:
EmployeeService (you would want to inject it to controller or other service)
EmployeeRepository / EmployeeDao
EmployeeController (it will be bean managed by Spring's MVC framework)
etc.
Spring beans are building blocks of your application. Let's suppose you need to create web application for storing and managing employees records (creating, retrieving, updating, deleting). What you will need is web controller that will handle incoming requests for several operations (EmployeeController). Good practice is that controller doesn't implement any business logic - all it should do is to delegate work to service beans. So you would need bean like EmployeeService. Then controller would ask service to do some work (give me employees list / remove John Smith from database / change salary for Ann Jackson / etc). So service will be controller's dependency (service is injected into controller). Service can also have some dependencies (like repository object, which is responsible for handling communication with data storage) and these dependencies would be injected to service. Dependency management is Spring's core feature.
Good practice in object oriented programming is to have small classes that are responsible for doing one kind of actions. Such objects are much easier to test and understand. The more classes you have, the building application from blocks is harder, so it's worth to delegate it to framework like Spring. Without Spring you would need to create controller class, then inside of it create service, then inside of it create other dependencies and so on. Spring does it for you, so all you need to do is to declare dependencies and they will be injected automatically. If you want to replace implementation of your service with another (for example repository that used XML file for storing data with repository storing data in relational database) then you just have to change your bean definition.
Regarding to beans managed by Spring, typical example is database transaction manager (eg. org.springframework.orm.jpa.JpaTransactionManager). If you define such bean, and declare which methods should be transactional, then Spring will take care of transactions management (will open, commit or rollback transactions automatically).
Is this good practice to mark service class with annotation #service and #repository , since I am doing most of my DB operations in my service class. Does spring treats them a singleton class or prototype?
It makes easier for Spring to target pointcuts with more specific annotations. So, you should code DB operations in DAO layer and annotate it with #Repository as it causes exceptions to be wrapped up as DataAccessExceptions. Also, coding related stuff in it's own layer give rise to code modularity and reuse.
Moreover using the specialized annotations help to clearly demarcate application layers, in a standard 3 tier application.
Does spring treats them a singleton class or prototype?
By default all beans are of Singleton scope in Spring. To make it serve as prototype you have to change the scope of bean.
I started my first web project using JSF, Hibernate and Spring and I would like to know if the architecture that I designed is the most appropriate.
The beans are annotated with #Controller, and the InventoryServiceImpl is annotated with #Service. I also use #Autowired for dependency injection. The AbstractDao has the Hibernate's SessionFactory attribute (it's not ServiceFactory as it says in the image, sorry about that) which is responsible for the access to the database itself, so the DAO's Implementations just calls methods of the AbstractDao superclass.
My concern is mainly regarding the Service, as I am not sure if only one class that accesses all DAOs is the wisest thing to do.
The UML diagram:
uml-diagram http://imagizer.imageshack.us/v2/1280x1024q90/673/ebfa7f.png
Any comments or suggestions are highly appreciated.