I have a architecture dillema. I've implemented Bean (#Named) BO and DAO. And I am not sure how communication should be implemented. Let's say I want to register user. I am filling the bean from JSF then I use userBO.registerUser(this) method on injected userBO. I am not sure what should happen next. I think validation should be BO's work and if everything is ok data should be passed to DAO. DAO should create UserEntity and persist it into database. But what if we create UserEntity in BO and pass it to DAO. I am a little bit confused.
BO should deal with any business logic.
If the creation of the UserEntity is related with any business logic (i.e. the attributes or the values need to be calculated according to a non-trivial logic rule) the creation might stay in the BO. If the creation is simple, and basically puts the values of the form in the object, it can be populated in a previous layer (Controller, or JSF, or whatever).
About the DAO, it should only persist a populated object into your database.
Hope this helps you!
Related
I would like to know, whether this is a valid practice to use "new" in spring to create a Object?
You can either use xml->bean to create a object using xml file or use annotations to create a object.
This question arises when I am working on a project and where I want to create a object of a property class(which contains properties and setter/getter method of those properties).
I am able to create a object using new and its working fine but if spring has capability to create and manage object lifecycle then which way I need to go create a object and why?
I think the confusion may arise because of the (over)usage of spring as DI mechanism. Spring is a framework providing many services. Bean or dependency injection is just on of those.
I would say that for POJOs which have just setter and getters without much logic in them you can safely create objects using new keyword. For example, in case of value objects and data classes which do not have much configuration or life cycle events to worry about, go ahead and crate those using new keyword. If you repetitively create these objects and have fields which are not changing often, then I would use spring because it will lessen some of the repetitive code and object creation can be considered externalized or separated from your object usage.
Classes instantiated using spring bean definition xml/annotations are basically 'Spring-Managed' beans which mostly means that their life cycle, scope, etc are managed by spring. Spring manages objects which are beans, which may have some life cycle methods and APIs. These beans are dependencies for the classes in which the are set. The parent objects call some API of these dependencies to fulfil some business cases.
Hope this helps.
The Dependency Injection concept in spring is more useful when we need to construct an object that depends upon many objects, because it saves you time and effort for constructing as well as instantiating dependent objects.
In your case , Since it's a POJO class with only setters and getters , I think it is absolutely safe to instantiate it using a new keyword.
Iam about to create a webapplication with JavaServer Faces 2. In the backend things are managed with other usual JEE technologies like EJB3.1 and JPA2. The point is, Iam following some domain driven architecture, which means, the the domain models are used at the JSF layer as backing bean models and are typically persisted as persistent entities at the persistence layer. Using the same model at different layers yields the advantage of only defining the related model restrictions once and for all. Using Bean Validation at this level provides the restrictions of this model to either JSF, JPA etc.
Now my question is, whether using bean validation with JSF2 is a good idea? My concerns are that linking the validation restrictions directly to the model might be the wrong approach, as the validation of the JSF lifecycle usually happens somehow earlier than accessing the model (for its validations rules). As much as I know JSF validation is not taking place during model processing (aka. phase 4: apply model values) but earlier in its own dedicated point in time (phase 3: process validations) and is applied on the component value (submitted value). However, how should the JSF validation (in phase 3) know the actual restrictions of the bean, if it is not validating during the model processing?
Thanks for any clarification on this.
[Edit]
To be more specific, right now Iam using Bean Validation for this purpose and it is working, as invalid values are rejected and a faces message is properly shown. I just wonder if it is the right approach, as to my understanding the validation might take place in the wrong JSF phase and thus might lead to an inconsist component model.
You can add all those bean validations in Data Transfer Object(DTO), The DTO's responsible for delevering the UI data in the JSF. After all the validations are succeed you can copy the DTO's to the Entity(Model) Object.
For copying the (DTO's to Entity) or (Entity to DTO's) we can use third party librires like dozer mapper.
This will avoid the validation restrictions directly to the model layer. I mean the Entity Objects
I am early in the architecting phase of a project -- there is no code to post. Basically, I have a controller retrieving a "Model bean" which roughly corresponds to the page/form: so it has form information (what checkboxes are selected, etc.) -- and also contains domain beans (database entity info).
How to get Spring to create "default" info for the "model beans" on the first use, but retrieve from session thereafter. And similarly, how to get Spring to create domain bean from persistence layer 1st time, but retrieve it from the session thereafter? EDIT: Using just annotations.
If I got your question right. This is what I have done.
Under LoginController I have condition to authenticate user. Then I add the user info in a bean and redirectAttrs.addFlashAttribute("mySession", thisIsUserSessionBean);
This is redirected to another controller called LandingController. Annotation under LandingController is something like below. Note: #SesssionAttributes annotation. You can add any information under this session object. My suggestion, keep the bean smaller for performance sake.
#Controller
#RequestMapping(value = "/homepage")
#SessionAttributes({"mySession"})
public class LandingController
I would not prefer to have domain bean sticked in session.
I am creating an application were I am using MVC pattern.For this I am considering my view as jsps,controller as servlets and model as DAO objects.I have a doubt that me considering DAO objects as Model is right or wrong?
Model is not a DAO. It is a layer, which contains all the domain logic, and is composed mostly from two types of elements, with following responsibilities:
business logic
data access (usually implemented as DataMapper)
The idea is that business logic should never be tied to the storage mechanism. When you are creating an invoice, the domain object should not care, if data comes from SQL database, MSWord document, remote REST API or just a mocked up data.
You might find this article interesting and relevant: GUI Architectures.
A model in MVC is where the business logic lives.
Looking at the sun Java EE pattern definitions we see that DAOs encapsulate persistence mechanisms and are used by a Business Object. I don't therefore see DAOs as natuarally having any business logic.
In simple systems, a few database tables, or those where the business logic is implemented in
the database (stored procedures, referential integrity checks, triggers) then the DAO is effectively a facade in front of Business Logic, so they pretty much look like the Model. So in some introductory material you may see the DAO as pretty much the only Java expression of the Model.
When we choose to implement our business logic in Java, it would lie in a layer above the DAO, in for example Session Beans, which use the DAOs, and in my mind it's the Session Bean or equivalent which is the Model.
So ask yourself: where is the business logic? That's where the Model really is.
I have an app written with Struts2 Spring3 JPA2 and hibernate. In this app i have the following levels :
- struts2 actions
- spring services
- spring DAO
So, one struts action call for a service which can contain calls to one or many dao objects.
In order to display the info on the screen i have created some "mirror" objects for entities; ie: EmailMessage entity has a EmailMessageForm bean that is used to display/gather data from webforms (i don`t know if this is the best practice), and hence my problem.
In EmailMessageServiceImpl i have a method called:
public List < EmailMessage > getEmailMessages(){
//code here
}
and, if i call this from struts action i cannot get dependencies because session has expired (i have TRANSACTION entity manager). So, one solution would be to create another method
List<EmailMessageForm> getEmailMessagesForDisplay()
{
//....
}
and here to call for getEmailMessages() and convert this to form objects.
What do you recommend me ?
What is the best practice for this kind of problem ?
If by "dependencies" you mean "lazy-loaded objects", IMO it's best to get all the required data before hitting the view layer. In your current architecture it looks like that would mean a service method that retrieves the DTOs ("form beans"; I hesitate to use the term since it's easy to confuse with Struts 1).
Some say using an Open Session in View filter/interceptor is better. It's easier, but can lead to unintended consequences if the view developer isn't paying attention, including multiple N+1 queries etc.