When you build an Adapter that connects your application and the database,
- How big should you make this adapter? Should it contain all possible queries that could be made to the DB?
- Do you split it up into several adapters?
- By what means should split it up?
I'm imagining the following rough architecture:
Application | | calls (e.g. db.queryData() ) ↓ DBAdapter | | calls (e.g. http request) ↓ Database
Let's think of an to be a
task list management application for multiple users. For this application You would need queries like
How would you organize these queries?
Would you build one adapter for all queries?
class DBAdapterSQL: queryTaskList(): ... queryTask(): ... queryUserInfo(): ... updateUserInfo(): ... createUser(): ...
In a big application this might lead to a class with hundreds of methods, which seems a little impractical and hard to maintain.
Would you divide the responsibility by domain?
class DBAdapterTasksSQL: queryTaskList(): ... queryTask(): ... class DBAdapterUserSQL: queryUserInfo(): ... updateUserInfo(): ... createUser(): ...
This approach has less methods per class. However, there are probably still many methods that remain unused for defined use cases:
E.g. A component responsible for (ultimately) getting a task list on the screen might never use
queryTask, because it does not need that level of detail per task.
Where would you locate queries that lie in the middle between tasks and users?
Would you divide the responsibility by use case?
class DBAdapterTaskReadingSQL: queryTaskList(): ... queryTask(): ... class DBAdapterTaskWritingSQL: upsertTask(): ... class DBAdapterUserReadingSQL: queryUserInfo(): ... class DBAdapterUserWritingSQL: updateUserInfo(): ... createUser(): ...