In my application, i'm attemping to create a many-to-many relation with additional fields
following this tutorial:
hibernate-many-to-many-example-join-table-extra-column-annotation
I would like to know what the best practice says about where to put DAO methods related to this relationship.
is it better to create a dao specific for the association (ex. StockCategoryDAO) or put the methods in the StockDAO / Category ?
For example, I get confused thinking about that:
ex.1 - a method which gives me all Stocks associated to a category...
i don't need that because i already have getter in Category model class... right?
ex.2 - i will have a page under the Stock panel, where i will select (checkboxes) which categories
are associated to this stock (the stock already exists in db).
After submit, in the controller i get all selected checkboxes (if you know an examples how to this, you are welcome) and i have to call a service method (which encapsulates my dao) to insert
the association.
In this case is it better to use the setter of Stock class, followed by a session.update(stock) or use a StockCategoryService.addCategoryService(...) for each category selected?
thanks for any advices
I would think the basic design should be "Every Model class should have its own DAO class that has all the methods defined, that operate on that particular model". This includes all getters too.
DAO methods are based on model.
So, you need to put all the getter methods for the Stock in the StockDAO class.
And you can define the RowMapper class as a inner class in the DAO class, if you are using jdbctemplate and if you want to return custom objects
I would suggest you to use JdbcTemplate class. This minimizes the code in DAO class.
Here I have listed the steps to carry out this implementation:
Declare the JdbcTemplate bean in spring.xml and inject the datasource bean as property o jdbcTemplate bean
(So during initialization itself JdbcTemplate is created with right datasurce)
Implement DAO class for every model. Define all the methods (including getters) inside the DAO class.
if your getter method returns custom object, implement rowMapper class as inner class in the DAO class.
(implementing rowMapper gives jdbcTemplate, a sense about the resultset)
Related
I want according to role value, to get associated service, like
LogisticsUserEntity user = this.getLogisticsUserById(userId);
UserDealService userDealService = getUserDealService(user.getRole());
UserEntity userEntity = userDealService.getUserEntity(user);
LogisticsUserDao and TruckOwnerDao both implement UserDealService interface.
If role is 4, driverDao return, if it is 5, truckOwnerDao return, but I have used
#Autowired
private DriverDao driverDao;
#Autowired
private TruckOwnerDao truckOwnerDao;
I don't want to use a map, like
put(4, driverDao);
because if I want to add other dao, I have to modify the code, it violates the open-closed.
So how can I solve the extend problem?
Thanks for all your help and suggestions in advance.
As it was already mentioned in comments, you need a factory, but there are few factories.
Factory - Creates objects without exposing the instantiation logic to the client and Refers to the newly created object through a common interface. Is a simplified version of Factory Method
Factory Method - Defines an interface for creating objects, but let subclasses to decide which class to instantiate and Refers to the newly created object through a common interface.
Abstract Factory - Offers the interface for creating a family of related objects, without explicitly specifying their classes.
I would consider factory method, that way Your "user" object would have method "user.createUserDealService()" which returns needed service.
Yet I'm not sure if this should be called service, services are objects that are remote callable.
By the way it looks strange for getting userEntity based on user. Isn't user an entity already?
I want to create a DAO class named BaseDAO that should have the JPA and JDBC capabilities in Spring. I mean, I want to extend JPADAOSupport and JDBCDAOSupport classes of spring in to my BaseDAO class. I am aware that multiple inheritance is not an option in Java.
I have created two separate Base classes like BaseJPADao and BaseJdbcDao extending the respective classes. Is it possible to have a single class to extend both? Is there any design pattern solving this issue. Please advise.
Why don't you have a DaoGateway bean having injected the actual JPA DAO and the JDBC DAO beans.
This gateway can then decide which DAO to delegate a given request (to JPA or to JDBC).
You should always favour composition vs inheritance when reusing functionalities.
no it is not. if it was possible, you would still have the same result as in
one class extending JPADAOSupport and JDBCDAOSupport, which you yourself say you know is not possible because multiple inheritance is impossible.
you can write to an interface, and provide two implementations, though.
This would be easy to do with delegation if they both had interface level access you want:
public class MyUberClass implements WhateverJPADAOSupportDoes, WhateverJDBCDAOSupportDoes {
private JPADAOSuport jpa;
private JDBCDAOSupport jdbc;
// now implement all methods specified by the interfaces on the class signature and delegate to their respective member
}
But it seems you want access to all of their public methods. As there is no interface for both you can do the same as above but it can't be of both types simultaneously. The language expressly denies you this.
Your only other option is to create an adapter interface that your code can rely on and then use the combination delegation. If you're hoping to have one class that you can just drop in as a substitution for both then the answer is you can't.
In a Wicket/Spring/Hibernate project I inherited I find the following pattern:
For each Entity there exists an abstract class called EntityHome generated by Hibernate Tools which provides methods for finding, persisting, merging, and removing Entity. In another package there are classes called EntityDao for each EntityHome which in most cases simply extend EntityHome without adding any additional functionality.
Normally I would create a single generic DAO for handling persist, find, merge, and remove generically and have all DAOs extend this one.
The closest thing to some kind of documentation for Home Objects I found is http://docs.jboss.org/seam/1.1GA/reference/en/html/framework.html#d0e6756 and what I read there pretty much matches what a DAO should do.
So my question is: what is the difference between a Home Object and a DAO? Is there any at all?
Getting right to it with a silly example:
Suppose I have created a FactoryBean implementation to create a Manager object.
public class ManagerFactory implements BeanFactory<Manager> {
// implemented methods from interface
}
Now, this factory needs to take a field called employeeId in order to look up an employee to prepopulate various fields of the Manager bean that the ManagerFactory creates (Yes, I know, in the real world Manager would extend Employee, lets pretend I can't do that).
So, since this employeeId field is not constant, is the only way to deal with this to create a setEmployeeId() method in the FactoryBean, then get the FactoryBean itself, then set the employeeId before calling getObject()?
Or am I making no sense whatsoever?
Jason
I want to create a DAO layer for my application. After some googling I found that many peoples uses Generic DAO approach (Don't repeat the DAO!).
But I did not like this approach.
What if I need slightly different interfaces between DAO for different DAO implementations? (i.e. methods in generic interface not exactly same which I want to create in my DAO implementations)
What if my entity's primary key consists of more than one attribute?
If you need a slightly different DAO for a particular entity, you can always extend a generic one(MySpecificDAO <....> extends GenericDAO<....>). Primary key can be composite itself, but it's impossible to have 2 primary keys .
Straight from the article you linked to:
Extending GenericDAO
The interface for each DAO is, of course, based on the GenericDao interface. I just need to adapt the interface to a specific domain class and extend it to include my finder methods. In Listing 6, you can see an example of the GenericDao interface extended for a specific purpose
Regarding your last question: by definition, an entity has one and only one primary key.
Disadvantage: you still have to implement the DAO. Stop following advice from 6 years ago, and use Spring Data repositories instead. Then you don't have to write any implementations at all.
What if I need slightly different interfaces between DAO for different
DAO implementations?
you can override the method in your GenericDaoImpl class. or create a new method.
What if my entity have 2 or more primary keys?
I guess you meant compound-key scenario. Note that usually the findOne/readOne/getOne method in GenericDao would expect a parameter, (T key) the T here is type, it could be composite primary key.
for example:
class PersonPK{
private String name;
private Date birthday;
.....
}
You can find here a Generic DAO a working and improved implementation of that very article. Just checkout the Example.java at the bottom of the page. In this example you can see how you can define "slightly different interfaces between DAO for different DAO
implementations".