I am currently going through a Spring Boot tutorial to build a Spring Data REST application.
The EmployeeRepository interface extends the Crud Repository interface. It is then used in a DatabaseLoader where we use its save, find, and delete methods that are inherited from EmployeeRepository.
My question is how can a class use an inherited method of an interface without defining it? I always thought that on implementation of an interface I must override all of its methods.
From the tutorial: "That is how we can write an empty interface and inherit already built save, find, and delete operations."
Spring data will create an implementation of that interface when the app is running and creating the necessatu beans and of course the persistance context and entity manager too
for that reason when you extends from CrudRepository you need to add the object class and the type of the id of your entity like arguments in order to create this specific object to be persisited in your database
Remember Spring Data JPA will help you with a jpa provider in this case hibernate in order to avoid EntityManagerFactory object and so on.
you can find more information about it here.
https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#reference
EmployeeRepository is an interface in your example, not an implementation, so it need not implement the methods. The actual implementation of the interfaces you are using is being provided by Spring Data.
Related
How would you guys elegantly name/baptize these classes, assuming prefix/sulfix like I, Impl, Dao, etc, are bad conventions!
I know it is possible to find many topics about naming convensions, but they are more about it than suggesting on how to handle those cases.
The ideia is to decouple any possible implementation between layers/modules and let the container to handle injections.
model: Company
company service interface: ICompanyService
service implementation class: CompanyService implements ICompanyService
persistence interface: ICompanyDao
persistence implementation class: CompanyDao implements ICompanyDao
I can't get rid of "I" at interface names cause interface and implementations would be named as the same (I know it is possible to use full name including package, but it is even uglier). Same case for CompanyDao. Also the same issue when DAO sulfix is removed because of model class name.
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?
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".
I am trying to auto generate some EJB service code, which are wrappers around Java DAO classes. DAO classes implement DAO interfaces, but also have their own public methods. This DAO layer is implemented by another team, so I cannot play around with it.
I am using CodeModel API to generate the code. I get each DAO class and want now to create the EJB Service code. Using java reflection I am trying to check if the method declared in the DAO class is an overridden implementing method of the interface or not. Is there anyway in which I can check that?
1) If overridden methods are with #Overridden annotation, than you could iterate through these methods, and check their annotation using this API: http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/reflect/Method.html#getDeclaredAnnotations%28%29
2) If there are no annotations, I think, the only way is to iterate through parent classes and interfaces and compare method signatures, declared there with signatures in your class.