I once inherited a codebase where everything was hidden behind two interfaces for no reason whatsoever.
A "Business Object interface" is implemented by a "Business Object implementation" which delegates its method calls to a "Data Access Object interface which defines exactly the same methods as the Business Object interface" which then is implemented by a "Data Access Object implementation" which then does a simple SQL query.
You can argue that the DAO has a right to exist. After all, you are separating concerns and organizing your codebase. The BO only exists to make me suffer through 4 layers of indirection. When I write code I just drop the DAO interface and call the original class DAO. If I ever need to migrate to something else, sure, I could just rename that damn thing to DAOImpl and create an interface with the same name as the original class and the same methods. I never had to.
A "Business Object interface" is implemented by a "Business Object implementation" which delegates its method calls to a "Data Access Object interface which defines exactly the same methods as the Business Object interface" which then is implemented by a "Data Access Object implementation" which then does a simple SQL query.
You can argue that the DAO has a right to exist. After all, you are separating concerns and organizing your codebase. The BO only exists to make me suffer through 4 layers of indirection. When I write code I just drop the DAO interface and call the original class DAO. If I ever need to migrate to something else, sure, I could just rename that damn thing to DAOImpl and create an interface with the same name as the original class and the same methods. I never had to.