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?
Related
I have two data source class, LocalDataSource and RemoteDataSource. In DataRepository, I need both the classes but on need basis. I don't want to inject both the classes in DataRepository constructor. Instead want to overload constructor with single data source class. How to implement this with dagger?
To directly answer the question: Dagger supports one #Inject constructor at most. You can use a #Provides method to call any constructor or factory method you'd like, but if you want Dagger to manage your dependencies it will only read the single constructor you specify with #Inject. That said, that's not quite the right solution here in any case.
If your class needs a LocalDataSource or a RemoteDataSource, and you don't know which one until runtime, inject a Provider<LocalDataSource> and Provider<RemoteDataSource> (or Lazy<LocalDataSource> and Lazy<RemoteDataSource>). These objects are inexpensive Dagger-implemented abstractions over your LocalDataSource and RemoteDataSource constructors, which Dagger automatically allows you to inject: For any T available in your graph, you can inject Provider<T> and Lazy<T> (or even Provider<Lazy<T>>, as described in the documentation).
In this way, Provider and Lazy can help you avoid creating either DataSource instance until you know which one you need.
The difference between them is that Lazy<T> will locally cache the object instance, acting like a field in your class. Provider<T> will always consult your Dagger Component, which will in most cases will return you a newly-allocated object unless you've applied a scope like #Singleton. If your objects are expensive to construct, Lazy is a good choice, since you'll only request one instance across the lifetime of your consumer; if they are cheap to construct, then you might even choose to use a Provider within a method and letting your object be garbage-collected as soon as it is no longer needed.
Of course, as Steven and AlphaOne point out in the comments, you might also consider a design where your DataRepository consumer accepts an arbitrary DataSource that you or Dagger can provide. This generally makes sense, as DataSource is likely a useful interface and DataRepository might not need to know implementation details of the source it consults. However, if you need to handle an arbitrary source specification at runtime, at some point you'll still need to inject both a #Local DataRepository and #Remote DataRepository (assuming you've created #Qualifier annotations #Local and #Remote), and at that point it makes even more sense to use a Provider/Lazy instead of creating both DataRepository objects and their respective DataSources.
I have a general question about Spring but which is a bit difficult to explain. So I will describe the situation I'm facing in order to make it easier to understand.
I have a simple #Singleton service that has a single method. I would like to use some helper classes to help me.
Every time the single method is called, I would like to be able to instantiate a new team of helper classes. As they need to work together, these classes need references to each other. But I don't want to construct them by myself. Once the method of the service returns, the helper instances can be GC.
Is it possible to use Spring to create a small team of helper classes all scoped to the call of the method in the #Singleton class ?
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.
This is a follow-up question to a previous question.
From what I understand, one #Controller-annotated class with #RequestMapping-annotated methods cannot successfully inherit from another because Spring can't recognize they're both mapping to the same method(s). Even if Spring recognized they were the same instance, it would have no way to decide which instance of the two controller beans to use to invoke the method.
But static methods are invoked independent of any instances of a class, and child classes do not carry their own copy of the parent's static members. Making all of my #RequestMapping-annotated methods static (at least on the parent class) could resolve this problem, which brings us to my question:
Can a public static method be used with #Controller on the class and #RequestMapping on the method? And would it behave about the same as a non-static method*?
* I know that a static method naturally can't access instance members, but controllers should typically be implemented in such a way that there aren't any instance variables anyway. All the methods I'm dealing with would work exactly the same if they were static methods, provided the framework allows for it.
It works fine for me in Spring 3.2.X. Though, controllers often have data members on their instances, but they're usually autowired instances that are services. So I wonder if you're misunderstanding the overall design pattern of the Spring framework.
I can't think of any real benefit in using a static method, the controller instance is already there, so even if you made the controller have all static methods it's still going to get instantiated. I would think the instance invocation overhead would be minuscule and lost in the noise as far as performance.
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.