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.
Related
I'm working in a company where JPA #transactional are used within #Component beans. I've always been told that #Transactional should be used inside #Service beans. Does someone could explain spring mechanisms differences between those and what are the best pratctices .. and why
There is no difference.
Also, #Service and #Component are the same. #Service is just a stereotype that developers often use to indicate that the Spring Bean is kind of a Service (maybe in a DDD meaning or not)
First of all, there is no difference.
From the spring javadoc
#Component
Indicates that an annotated class is a "component". Such classes are considered candidates for auto-detection when using annotation-based configuration and classpath scanning.
...
#Transactional
Indicates that an annotated class is a "Service", originally defined by Domain-Driven Design (Evans, 2003) as "an operation offered as an interface that stands alone in the model, with no encapsulated state."
May also indicate that a class is a "Business Service Facade" (in the Core J2EE patterns sense), or something similar. This annotation is a general-purpose stereotype and individual teams may narrow their semantics and use it as appropriate.
This annotation serves as a specialization of #Component, allowing for implementation classes to be autodetected through classpath scanning.
Frankly speaking, they behave in the same way.
By using #Transactional annotation on a public method or class it simply creates a proxy with transaction code for you.
IMO great explanation of #Transactional
Spring Stereotype Annotations
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.
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 have a huge set of really old Portlets code I am being required to "refactor" due to a bug that was found in Prod. The refactor is requiring me to update to a new library, and as a result move from a custom DAO structure using "Query" classes to one that uses Springs JdbcTemplate and annotations to wire everything together.
BUT, there are a LOT of portlets. Is there a way to use Spring with Annotations for DI that does NOT require me to completely re-write the Portlet to use DispatcherPortlet and the #RequestMappings? I just want to mark all the Portlets, and the handful of Servlets as well, with #Component just to have Spring inject the classes I need. Where I am struggling is in how to bootstrap the ApplicationContext without using the Spring-provided dispatcher portlet/servlet to initiate the context. I would like to not have to use the ApplicationContext directly to pull the necessary beans out by hand, if possible. I do have contextConfigLocation and the ContextLoaderListener defined in my web.xml already.
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.