Database Agnosticism with Design Patterns

Imagine you have an app that needs to talk to different types of databases — maybe an SQL database today, a NoSQL database tomorrow, or even an in-memory database for testing. Managing all these connections and queries can get messy fast. That’s where the Repository design pattern in Python comes to the rescue!

In simple terms, the Repository pattern acts like a smart librarian for your data. It knows how to get, save, and update data without you needing to worry about where the data is stored or how to talk to it. This makes your code cleaner and more organized.

Repository Desing pattern

In this story, we’ll show you how to create a repository that can easily switch between different databases. We’ll start by designing a common interface — like a contract that all our databases will follow. Then, we’ll create specific repositories for each type of database. Finally, we’ll see how easy it is to swap out one database for another without changing the rest of our app.

By the end, you’ll see how the Repository pattern makes your code flexible, easier to manage, and ready for anything the future throws at it.

Utilizing the Repository Pattern in Python with a Simple Hack

Step 1: Define the Repository Interface

First, we create an interface that outlines the basic operations our repositories will perform. This ensures all repositories behave the same way.

from abc import ABC, abstractmethod

class IRepository(ABC):

    @abstractmethod
    def get_by_id(self, id):
        pass

    @abstractmethod
    def get_all(self):
        pass

    @abstractmethod
    def add(self, entity):
        pass

    @abstractmethod
    def update(self, id, entity):
        pass

    @abstractmethod
    def delete(self, id):
        pass

Step 2: Implement Repositories for Different Databases

Next, we create concrete implementations for each type of database. Let’s start with an SQL database:

import sqlite3

class SQLRepository(IRepository):
    def __init__(self, db_path):
        self.conn = sqlite3.connect(db_path)

    def get_by_id(self, id):
        cursor = self.conn.cursor()
        cursor.execute("SELECT * FROM data WHERE id=?", (id,))
        return cursor.fetchone()

    def get_all(self):
        cursor = self.conn.cursor()
        cursor.execute("SELECT * FROM data")
        return cursor.fetchall()

    def add(self, entity):
        cursor = self.conn.cursor()
        cursor.execute("INSERT INTO data (name, value) VALUES (?, ?)", (entity['name'], entity['value']))
        self.conn.commit()

    def update(self, id, entity):
        cursor = self.conn.cursor()
        cursor.execute("UPDATE data SET name=?, value=? WHERE id=?", (entity['name'], entity['value'], id))
        self.conn.commit()

    def delete(self, id):
        cursor = self.conn.cursor()
        cursor.execute("DELETE FROM data WHERE id=?", (id,))
        self.conn.commit()

Now, let’s create a repository for a NoSQL database, like MongoDB:

from pymongo import MongoClient

class MongoRepository(IRepository):
    def __init__(self, db_name, collection_name):
        self.client = MongoClient()
        self.collection = self.client[db_name][collection_name]

    def get_by_id(self, id):
        return self.collection.find_one({"_id": id})

    def get_all(self):
        return list(self.collection.find())

    def add(self, entity):
        self.collection.insert_one(entity)

    def update(self, id, entity):
        self.collection.update_one({"_id": id}, {"$set": entity})

    def delete(self, id):
        self.collection.delete_one({"_id": id})

Hack: Implement a Factory for Creating Repositories

Here’s a simple yet powerful hack to make your Repository design pattern even more flexible and easy to use. By incorporating the Factory design pattern, you can create repositories for different databases on the fly, just by specifying the driver name. This way, you don’t need to worry about the specific class names or implementations. It works like magic!

Step 3: Implement a Factory for Creating Repositories

1. Create the Factory Class:The RepositoryFactory class will have a static method create_repository that takes the driver name and other necessary parameters. Based on the driver name, it will return the appropriate repository instance.
2. Define the Factory Method:Inside the create_repository method, we check the driver name and instantiate the corresponding repository class. If an unknown driver is passed, it raises an error.

class RepositoryFactory:
    @staticmethod
    def create_repository(driver, **kwargs):
        if driver == "sqlite3":
            return SQLRepository(kwargs.get('db_path'))
        elif driver == "mongo":
            return MongoRepository(kwargs.get('db_name'), kwargs.get('collection_name'))
        else:
            raise ValueError(f"Driver '{driver}' is not implemented yet.")

Using the Factory:Now, instead of directly instantiating repository classes, you use the factory method. This way, you can easily switch databases without changing your business logic. Here’s how you can use it in your main application:

def main():
    # Using the factory to create a SQLRepository
    sql_repo = RepositoryFactory.create_repository("sqlite3", db_path='example.db')
    sql_repo.add({'name': 'Item 1', 'value': 'Value 1'})
    print(sql_repo.get_all())

    # Using the factory to create a MongoRepository
    mongo_repo = RepositoryFactory.create_repository("mongo", db_name='example_db', collection_name='data')
    mongo_repo.add({'name': 'Item 2', 'value': 'Value 2'})
    print(mongo_repo.get_all())

    # Attempting to use an unknown driver
    try:
        unknown_repo = RepositoryFactory.create_repository("unknown")
    except ValueError as e:
        print(e)

if __name__ == "__main__":
    main()

Why This Hack is Awesome

• Simplicity: You only need to remember the driver names, not the specific repository class names.
• Flexibility: Easily switch between different databases by changing a single parameter.
• Scalability: Add new database types by simply extending the factory method without modifying existing code.
• Maintainability: Centralized repository creation logic makes it easier to manage and extend.

By using this hack, you combine the power of the Repository and Factory patterns to create a dynamic, easy-to-use, and maintainable data access layer. It’s a straightforward approach that enhances the flexibility and scalability of your application.

Achieving Database Agnosticism with Design Patterns

By implementing the Repository and Factory design patterns, we can achieve database agnosticism in many cases. Here’s how these patterns help:

Repository Pattern:

• Abstraction of Data Access: The Repository pattern provides a consistent API for data access operations, hiding the specifics of the underlying database. This abstraction allows the business logic to interact with data repositories without needing to know which database is being used.
• Interchangeable Implementations: Different database-specific repositories implement the same interface. This means you can switch from one database to another (e.g., from SQL to NoSQL) without changing the business logic. The interface ensures that the methods for fetching, saving, and updating data remain consistent across different databases.

Factory Pattern:

• Dynamic Repository Creation: The Factory pattern enables the creation of repository instances based on the specified driver (e.g., “sqlite3” or “mongo”). By centralizing the creation logic in a factory class, you can dynamically select and instantiate the appropriate repository at runtime.
• Error Handling for Unsupported Databases: The factory method can handle cases where an unsupported or unknown database driver is specified, providing clear error messages and maintaining robustness.

How It Works

When you use these design patterns together, you achieve database agnosticism as follows:

• Uniform Interface: Your application code interacts with a uniform interface (the repository interface), making it agnostic to the type of database being used.
• Seamless Switching: By simply changing the parameters passed to the factory, you can switch databases without modifying your business logic.
• Ease of Extension: Adding support for new databases requires implementing a new repository class and updating the factory method, leaving the rest of your application unaffected.

# Creating a repository instance using the factory
repo = RepositoryFactory.create_repository("sqlite3", db_path='example.db')

# Using the repository without worrying about the underlying database
repo.add({'name': 'Item 1', 'value': 'Value 1'})
items = repo.get_all()
print(items)

# Switching to a different database
repo = RepositoryFactory.create_repository("mongo", db_name='example_db', collection_name='data')
repo.add({'name': 'Item 2', 'value': 'Value 2'})
items = repo.get_all()
print(items)

In this example, the business logic for adding and retrieving items remains the same regardless of the underlying database. This demonstrates how the Repository and Factory patterns work together to achieve database agnosticism, allowing your application to be flexible, maintainable, and ready to adapt to future changes in data storage requirements.