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.
Related
I code CRUD methods and wonder if it's useful to define my DAO class as singleton. While they have as a parameter the context of the activity that requires them.
I do not try to do it because I learned about the net. And I notice that the singleton is used in the classes that manage a database outside the activities
I wouldn't use a singleton. It's a recognised anti-pattern, and makes testing difficult. I would much rather inject in a concrete implementation, and have your service reference a DAO interface (allowing you to inject different implementations in)
Basically I have a database with each table linking to a DAO class and a class that defines my table. My DAO class when I instantiate it I have in parameter the context to activate it. This makes it possible not to have calls from everywhere. Do I still need to implement a singelton?
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.
In my Java Spring application I have a DAO class with methods. I would like to know which access modifier use: protected or public?
In which situation we should use protected modifier? I don't know when I should use a protected modifier, so I always use public. Is it proper way?
DAO layer is mostly used for database transactions. For eg: saving, updating, fetching, etc.
Now they don't have any business logic in them, because we put the business logic in the Service layer. Usually this Service layer makes a call to the DAO layer whenever it needs to perform a database related work.
Therefore, public should be used in most cases (as they are getting called from a different layer/package) all together.
Protected is good when you are sure that you will make call only from the same package(or sub classes), which may not always be the case. So no, protected is not recommended.
Protected doesn't really make sense for DAOs, since you need the methods in other packages, in classes which don't implement the DAO. Therefore public is almost always the way to go.
For DAO classes, you should make an interface with Dao methods declared(Which will obviously be public). Your DAO classes should extend the interface. In this way your Dao methods will be accessed from other classes via the interface reference.
It's the better way, because it will be easy to test. You can provide a mock implementation of the DAO interface to test your code. You can do this before you write your actual DAO class. If you are calling DAO methods with interface reference variable, then you can change your DAO class and it will still work because you are changing the class not the interface whose reference you are using for calling the methods(renaming class name for an example).
It's the important design principle that you should always code for interface wherever possible. I recommend you to see this answer to read about why you should code for interfaces in DAO.
You should use protected modifier in case of inheritance. When you want outside the package only child classes should be able to access the methods and properties of your class. when you need to do somethings that should not exposed in public API but still needs to be overriden by subclasses for example template method pattern.
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".
Sometimes, I find some class names including Aware such as ApplicationContextAware and MessageSourceAware (spring). Does this Aware have any special meanings or is it a famous rule?
Those are not classes, are interfaces. The name is just a convention on Spring meaning that some special framework object is going to be injected to that class if it is managed by the framework.
Directly from the docs of ApplicationContextAware:
Interface to be implemented by any object that wishes to be notified of the ApplicationContext that it runs in.
In this case, the bean that implements this interface will get a reference to the ApplicationContext managing the application.
Appending adjectives like "aware" to the end is a naming scheme often used for Java interfaces. This can then be implemented by classes, and the resulting is code which is more fluent to read for human beings, like
class Broker implements ApplicationContextAware { /* ... */ }
where it's quite easy to see that this class is a broker for something, and it knows how to deal with application contexts. Besides that, the "Aware" suffix has no special meaning from the Java (compiler) perspective.
The interfaces you cite seem to be a Spring-specific convention for allowing objects to interact with the dependency injection container that created them. By implementing the interface, a class signals that it wants certain information from the container and at the same time provides a method through which to pass that information.
I'd see it simply as an attempt to find a generic name for an interface that offers such functionality, not necessarily a strong convention with a specific technical meaning.
The concept of aware interfaces:
If I want the reference of objects of spring classes like XmlBeanFactory,ApplicationContext... In 2 or more classes, then there are 3 possible ways are there.
creating 2 BeanFactories in two classes.
creating at one class and sharing to all required classes .
In the 1st case ,we are unnecessarely creating 2 BeanFactories.
In the 2nd case, classes are tightly coupled with each other.
If our class implements BeanFactoryAware interface and overrides the contractual method called public BeanFactory setBeanFactory(BeanFactory factory) then IOC container see that special interface and calls setBeanFactory method by setting BeanFactory reference to that.
In 3. case above two problems are not there.