Complete Guide to the Django Services and Repositories Design Pattern with the Django REST Framework
Tags: webdev, django, backend, api
Published: 2024-07-08 16:59:18

## Introduction to the Django Services and Repositories Design Pattern with Django REST Framework

[**You can find the complete code and structure of the project in the following GitHub link:** *<mark>Click</mark>*](https://github.com/MateoRamirezRubio1/mini-blog-rest-api).

In the world of software development, code organisation and maintainability are crucial to the long-term success of any project. In particular, when working with frameworks like Django and the Django REST Framework to build robust web applications and APIs, it's essential to follow design patterns that help us keep our code clean, modular and easy to scale.

In this blog, we will explore one of these widely used design patterns: Services and Repositories. This pattern allows us to separate the concerns of data access and business logic, improving the structure and clarity of our code. Through this approach, we not only make our applications easier to maintain and test, but also more flexible and future-proof.

Join us as we break down this pattern step-by-step, from initial project setup to service and repository deployment, and discover how it can transform the way you develop your Django apps.

The realisation of the project is divided into three main sections: the structuring and design of the project; the coding of the structured project; testing.

[**You can find the complete code and structure of the project in the following GitHub link:** *<mark>Click</mark>*](https://github.com/MateoRamirezRubio1/mini-blog-rest-api).

---

## Creation and design of the project

In this first section, we will see how to create a new Django project with DRF (Django REST Framework) and we will analyse how the main parts of the project and REST APIs will be structured.

1. ### Start and creation of the Django project
    
    Before starting the project, you must install Django and Django REST Framework if you don't already have it:
    
    ```bash
    pip install django djangorestframework
    ```
    
    Now that we've installed the main tools we're going to use for the project, we'll create a new Django project using the `django-admin startproject` command:
    
    ```bash
    django-admin startproject my_project_blog
    ```
    
    This command generates the basic structure of a Django project, including configuration files and a project directory.
    
2. ### Creation of Django applications
    
    For this small blog project, we will have two main functionalities which we will divide into two Django apps: `Posts` and `Comments`.
    
    For this, in the terminal, inside the main project directory (my\_project\_blog), create two applications: `Posts` and `Comments` using the python command `manage.py startapp`:
    
    ```bash
    python manage.py startapp posts
    python manage.py startapp comments
    ```
    
    Apps are modular Django components that group related functionalities. In this case, `Posts` will handle blog posts and `Comments` will handle comments.
    
3. ### **File settings:**
    

Add the created apps and the DRF to the `INSTALLED_APPS` section in the project settings file: `/my_project_blog/my_project_blog/settings.py` :

```python
INSTALLED_APPS = [
    "rest_framework",
    "apps.posts",
    "apps.comments",
...
```

4. ### Project structure:
    

Next I will show you how the project will be structured, you can create all the directories/folders and files (ignore `README.md`, `.env`, `.gitignore`), and then we will fill them with code as we learn.

* **Main structure:**
    
    
![Main structure Image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zix4lbbyexs80tg57xoh.png)


    
* **Structure of the Comments app:**
    
    
![Structure of the Comments app Image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/irebacb1qw9q9gfswbc4.png)


    
* **Structure of the Posts app:**
    
    
![Structure of the Posts app Image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qhzkzv5mly9p8ug6erif.png)


    

5. ### System design:
    

For the realisation of the project we opted for an architecture based on layers and classic design patterns such as Repository and Services.

The Services and Repositories pattern divides business logic (services) and data access logic (repositories) into separate layers:

| Layer | Description |
| --- | --- |
| **Web Layer** | It presents the data to users. In this case, the views are for both REST APIs (using DRF) and web views (using Django Views). ***<mark>Note:</mark>*** REST APIs views handle all the API logic (CRUD, etc), while web views only handle sending data to the user via templates. |
| **Service layer** | Contains the business logic. It communicates with the `Repository Layer` to retrieve data and performs additional operations (without interacting directly with the database) before returning data to the views or controllers. |
| **Repository Layer** | It is responsible for interacting directly with the database. This layer is responsible for basic CRUD operations. ***<mark>Note:</mark>*** This layer is the only one in charge of interacting directly with the database. |
| **Model Layer** | Data models representing the database tables. |


![Arquitecture Pattern](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ic2bnd902divq7h31yt3.png)



We will delve a little deeper into each layer later as we code.

6. ### Design of REST APIs
    

REST APIs allow communication between the frontend and the backend. We use the Django REST Framework to create RESTful APIs. This is the structure we have for their respective naming and functions:

| HTTP Method | Endpoint | Description |
| --- | --- | --- |
| **GET** | `/posts/` | Gets a list of all posts. |
| **POST** | `/posts/` | Create a new post in the database. |
| **GET** | `/posts/{post_id}/` | Gets the details of a specific post. |
| **PUT** | `/posts/{post_id}/` | Update a specific post. |
| **DELETE** | `/posts/{post_id}/` | Delete a specific post. |
| **GET** | `/posts/{post_id}/comments/` | Gets a list of comments for a post. |
| **POST** | `/posts/{post_id}/comments/` | Create a new comment for a post. |
| **GET** | `/posts/{post_id}/comments/{comment_id}/` | Gets the details of a comment on a post. |
| **PUT** | `/posts/{post_id}/comments/{comment_id}/` | Update a comment on a post. |
| **DELETE** | `/posts/{post_id}/comments/{comment_id}/` | Remove a comment from a post. |

---

## Coding and deepening

Now that we are clear about the layout of the project, for the second section, we will code our blogging project by delving into several of the layers we talked about earlier.

1. ### Model:
    
    The Model represents the data. It defines the database tables. In Django, models are classes that inherit from `models.Model`.
    
    For this project we will create two models, one for each Django app:
    

| Modelo | Fields | Description |
| --- | --- | --- |
| **Post** | `'title', 'content'` | It represents a blog post. |
| **Comment** | `'post', 'content'` | Represents a comment associated with a post. |

* **In the archive:**`/my_project_blog/apps/posts/models.py` :
    

```python
class Post(models.Model):
    title = models.CharField(max_length=200)
    content = models.TextField()
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    def __str__(self):
        return self.title
```

* **In the archive:**`/my_project_blog/apps/comments/models.py` :
    

```python
from apps.posts.models import Post


class Comment(models.Model):
    post = models.ForeignKey(Post, related_name="comments", on_delete=models.CASCADE)
    content = models.TextField()
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    def __str__(self):
        return self.content[:20]
```

2. ### Views
    

The View handles user requests and returns responses. Django offers both class-based views (CBV) and function-based views (FBV).

`CommentListView` and `CommentDetailView` are examples of Class-Based Views (CBV).

Separation of concerns is a design principle that promotes the separation of a program into distinct sections, with each section addressing a separate concern.

As we saw earlier for this project, we separated the views into two:

* **API REST Views:** Handle API-specific logic, such as serialisation, validation and returning JSON responses.
    
* **Traditional Django Views (Web Views):** They handle rendering templates, session management and other web-specific logic.
    

**For the Posts app:**

* **In the archive:**`/my_project_blog/apps/posts/views/api_views.py` :
    

```python
from rest_framework import generics
from ..serializers import PostSerializer
from ..services.post_service import PostService

# API view for listing all posts and creating a new post.
# Utilizes Django REST Framework's ListCreateAPIView for listing and creating resources.
class PostListCreateAPIView(generics.ListCreateAPIView):
    serializer_class = PostSerializer  # Defines the serializer class used for converting model instances to JSON and vice versa.

    # Fetches all posts from the database.
    # `get_queryset` method specifies the queryset for listing posts.
    def get_queryset(self):
        return (
            PostService.get_all_posts()
        )  # Delegates the database query to the PostService layer.

    # Handles the creation of a new post.
    # `perform_create` is called after validation of the serializer.
    def perform_create(self, serializer):
        # Creates a new post using validated data from the serializer.
        PostService.create_post(
            serializer.validated_data
        )  # Uses PostService to handle creation logic.

# API view for retrieving, updating, and deleting a specific post.
# Extends RetrieveUpdateDestroyAPIView for detailed operations on a single resource.
class PostRetrieveUpdateDestroyAPIView(generics.RetrieveUpdateDestroyAPIView):
    serializer_class = PostSerializer  # Specifies the serializer class for retrieving, updating, and deleting resources.

    # Retrieves a post object based on the provided post_id.
    # `get_object` method returns the post instance for the specified post_id.
    def get_object(self):
        post_id = self.kwargs.get("post_id")  # Extracts post_id from the URL kwargs.
        post = PostService.get_post_by_id(
            post_id
        )  # Fetches the post using PostService.
        if post is None:
            raise NotFound(
                "Comment not fund"
            )  # Raises a 404 error if the post does not exist.
        return post  # Returns the post instance.

    # Updates an existing post instance.
    # `perform_update` is called after the serializer's data is validated.
    def perform_update(self, serializer):
        post_id = self.kwargs["post_id"]  # Extracts post_id from the URL kwargs.
        # Updates the post with new data.
        PostService.update_post(
            serializer.validated_data, post_id
        )  # Delegates the update logic to PostService.

    # Deletes a post instance.
    # `perform_destroy` is called to delete the specified post.
    def perform_destroy(self, instance):
        post_id = self.kwargs["post_id"]  # Extracts post_id from the URL kwargs.
        # Deletes the post using PostService.
        PostService.delete_post(post_id)  # Delegates the deletion logic to PostService.
```

* **In the archive:**`/my_project_blog/apps/posts/views/web_views.py` :
    

```python
from django.views.generic import ListView, DetailView
from ..models import Post
from ..services.post_service import PostService

# Class-based view for listing all posts in the web interface.
# Utilizes Django's ListView to handle displaying a list of posts.
class PostListView(ListView):
    model = Post  # Specifies the model to be used in the view.
    template_name = (
        "posts/post_list.html"  # Path to the template for rendering the list of posts.
    )
    context_object_name = "posts"  # Context variable name to be used in the template.

    # Overrides the default get_queryset method to fetch all posts from the service layer.
    def get_queryset(self):
        return (
            PostService.get_all_posts()
        )  # Delegates the database query to the PostService.

# Class-based view for displaying the details of a single post.
# Utilizes Django's DetailView to handle displaying detailed information of a single post.
class PostDetailView(DetailView):
    model = Post
    template_name = "posts/post_detail.html"
    context_object_name = "post"

    # Overrides the default get_object method to fetch a specific post based on post_id.
    def get_object(self, queryset=None):
        post_id = self.kwargs.get("post_id")  # Extracts post_id from the URL kwargs.
        return PostService.get_post_by_id(
            post_id
        )  # Fetches the post using the PostService.
```

**For the Comments app:**

* **In the archive:**`/my_project_blog/apps/comments/views/api_views.py` :
    

```python
from rest_framework import generics
from ..serializers import CommentSerializer
from ..services.comment_service import CommentService
from rest_framework.exceptions import NotFound

class CommentListCreateAPIView(generics.ListCreateAPIView):
    serializer_class = CommentSerializer

    def get_queryset(self):
        # Retrieve the 'post_id' from the URL kwargs. This ID is used to filter comments related to a specific post.
        post_id = self.kwargs.get("post_id")
        # Fetch comments related to the given post ID using the CommentService. The repository layer handles actual data fetching.
        return CommentService.get_comments_by_post_id(post_id)

    def perform_create(self, serializer):
        # Retrieve the 'post_id' from the URL kwargs. This ID is used to associate the new comment with a specific post.
        post_id = self.kwargs.get("post_id")
        # Create a new comment for the specified post using the CommentService. The service layer handles data manipulation.
        CommentService.create_comment(serializer.validated_data, post_id)

class CommentRetrieveUpdateDestroyAPIView(generics.RetrieveUpdateDestroyAPIView):
    serializer_class = CommentSerializer

    def get_object(self):
        # Retrieve the 'post_id' and 'comment_pk' from the URL kwargs.
        # 'post_id' is used to ensure the comment belongs to the post, while 'comment_pk' identifies the specific comment.
        post_id = self.kwargs.get("post_id")
        comment_id = self.kwargs.get("comment_pk")
        # Fetch the specific comment for the given post ID and comment ID using the CommentService.
        # Raise a 404 error if the comment is not found.
        comment = CommentService.get_comment_by_post_and_id(post_id, comment_id)
        if comment is None:
            raise NotFound("Comment not fund")
        return comment

    def perform_update(self, serializer):
        # Retrieve the 'comment_pk' from the URL kwargs for updating the specific comment.
        comment_id = self.kwargs["comment_pk"]
        # Update the specified comment using the CommentService. The service layer handles data manipulation.
        CommentService.update_comment(serializer.validated_data, comment_id)

    def perform_destroy(self, instance):
        # Retrieve the 'comment_pk' from the URL kwargs for deleting the specific comment.
        comment_id = self.kwargs["comment_pk"]
        # Delete the specified comment using the CommentService. The service layer handles data manipulation.
        CommentService.delete_comment(comment_id)
```

* **In the archive:**`/my_project_blog/apps/comments/views/api_views.py` :
    

```python
from django.views.generic import ListView, DetailView
from ..models import Comment
from ..services.comment_service import CommentService

class CommentListView(ListView):
    model = Comment
    template_name = "comments/comment_list.html"
    context_object_name = "comments"

    def get_queryset(self):
        # Extract 'post_id' from URL parameters to fetch comments associated with a specific post.
        post_id = self.kwargs.get("post_id")
        # Use the CommentService to retrieve comments for the specified post.
        # The service layer handles data access logic, keeping the view simple.
        return CommentService.get_comments_by_post_id(post_id)

    def get_context_data(self, **kwargs):
        # Get the default context from the parent class and add additional context for 'post_id'.
        context = super().get_context_data(**kwargs)
        # Include 'post_id' in the context so it can be used in the template.
        # This is necessary for rendering links or forms related to the post.
        context["post_id"] = self.kwargs.get("post_id")
        return context

class CommentDetailView(DetailView):
    model = Comment
    template_name = "comments/comment_detail.html"
    context_object_name = "comment"

    def get_object(self, queryset=None):
        # Extract 'post_id' and 'comment_id' from URL parameters to retrieve a specific comment for a post.
        post_id = self.kwargs.get("post_id")
        comment_id = self.kwargs.get("comment_id")
        # Use the CommentService to retrieve the specific comment based on 'post_id' and 'comment_id'.
        # If the comment is not found, `CommentService.get_comment_by_post_and_id` will return None.
        # In this case, a 404 error will be raised automatically by the `DetailView` if the object is not found.
        return CommentService.get_comment_by_post_and_id(post_id, comment_id)
```

3. ### Repositories
    

Repositories handle data persistence and encapsulate data access logic. They are defined in separate files (`repositories.py`) within each application.

**For the Post app:**

* **In the archive:**`/my_project_blog/apps/posts/repositories/post_repository.py` :
    

```python
from ..models import Post

class PostRepository:
    # Fetch all posts from the database
    @staticmethod
    def get_all_posts():
        return Post.objects.all()

    # Fetch a specific post by its primary key (ID)
    @staticmethod
    def get_post_by_id(post_id):
        return Post.objects.get(pk=post_id)

    # Create a new post with the provided data
    @staticmethod
    def create_post(data):
        return Post.objects.create(**data)

    # Update an existing post with the provided data
    @staticmethod
    def update_post(data, post_id):
        post = Post.objects.get(pk=post_id)
        for attr, value in data.items():
            setattr(post, attr, value)  # Dynamically update each attribute
        post.save()
        return post

    # Delete a post by its primary key (ID)
    @staticmethod
    def delete_post(post_id):
        post = Post.objects.get(pk=post_id)
        post.delete()
```

**For the Comments app:**

* **In the archive:**`/my_project_blog/apps/comments/repositories/comment_repository.py` :
    

```python
from ..models import Comment

class CommentRepository:
    @staticmethod
    def get_comments_by_post_id(post_id):
        # Retrieve all comments associated with a specific post_id
        return Comment.objects.filter(post_id=post_id)

    @staticmethod
    def get_comment_by_post_and_id(post_id, comment_id):
        # Retrieve a specific comment by post_id and comment_id
        try:
            return Comment.objects.get(post_id=post_id, id=comment_id)
        except Comment.DoesNotExist:
            # Return None if no comment is found
            return None

    @staticmethod
    def create_comment(data, post_id):
        # Create a new comment associated with a specific post_id
        return Comment.objects.create(post_id=post_id, **data)

    @staticmethod
    def update_comment(data, comment_id):
        # Update an existing comment identified by comment_id
        comment = Comment.objects.get(pk=comment_id)
        for attr, value in data.items():
            setattr(comment, attr, value)
        comment.save()
        return comment

    @staticmethod
    def delete_comment(comment_id):
        # Delete an existing comment identified by comment_id
        comment = Comment.objects.get(pk=comment_id)
        comment.delete()
```

4. ### Services
    

Services contain the business logic and act as intermediaries between views and repositories. They are defined in separate files (`services.py`) within each application.

**For the Post app:**

* **In the archive:**`/my_project_blog/apps/posts/services/post_service.py` :
    

```python
from ..repositories.post_repository import PostRepository

class PostService:
    @staticmethod
    def get_all_posts():
        # Retrieve all posts from the repository
        return PostRepository.get_all_posts()

    @staticmethod
    def get_post_by_id(post_id):
        # Retrieve a post by its ID from the repository
        return PostRepository.get_post_by_id(post_id)

    @staticmethod
    def create_post(data):
        # Create a new post with the given data
        return PostRepository.create_post(data)

    @staticmethod
    def update_post(data, post_id):
        # Update an existing post with the given data
        return PostRepository.update_post(data, post_id)

    @staticmethod
    def delete_post(post_id):
        # Delete a post by its ID from the repository
        return PostRepository.delete_post(post_id)
```

**For the Comments app:**

* **In the archive:**`/my_project_blog/apps/comments/services/comment_service.py` :
    

```python
from ..repositories.comment_repository import CommentRepository

class CommentService:
    @staticmethod
    def get_comments_by_post_id(post_id):
        # Delegate the task of retrieving comments by post_id to the repository layer
        return CommentRepository.get_comments_by_post_id(post_id)

    @staticmethod
    def get_comment_by_post_and_id(post_id, comment_id):
        # Delegate the task of retrieving a specific comment by post_id and comment_id to the repository layer
        return CommentRepository.get_comment_by_post_and_id(post_id, comment_id)

    @staticmethod
    def create_comment(data, post_id):
        # Delegate the task of creating a new comment to the repository layer
        return CommentRepository.create_comment(data, post_id)

    @staticmethod
    def update_comment(data, comment_id):
        # Delegate the task of updating an existing comment to the repository layer
        return CommentRepository.update_comment(data, comment_id)

    @staticmethod
    def delete_comment(comment_id):
        # Delegate the task of deleting a comment to the repository layer
        return CommentRepository.delete_comment(comment_id)
```

5. ### Serializers
    

Serializers convert complex data into native data formats (JSON) and vice versa. Serialisers are an important part of creating REST APIs with DRF which are not usually used in a normal Django project.

**For the Post app:**

* **In the archive:**`/my_project_blog/apps/posts/serializers.py`
    

```python
from rest_framework import serializers
from .models import Post

# Serializer for the Post model
# This class is responsible for converting Post instances into JSON data and validating incoming data for creating or updating posts.
class PostSerializer(serializers.ModelSerializer):

    # Meta class specifies the model and fields to be used by the serializer.
    class Meta:
        model = Post  # The model associated with this serializer. It tells DRF which model the serializer will be handling.
        fields = "__all__"  # Specifies that all fields from the model should be included in the serialization and deserialization process.
```

**For the Comments app:**

* **In the archive:**`/my_project_blog/apps/comments/serializers.py` :
    

```python
from rest_framework import serializers
from .models import Comment

# CommentSerializer is a ModelSerializer that automatically creates fields and methods for the Comment model.
class CommentSerializer(serializers.ModelSerializer):
    class Meta:
        model = Comment  # The model that this serializer will be based on.
        fields = "__all__"  # Automatically include all fields from the Comment model.
```

6. ### Configuration of URLs
    

URLs are organised into two separate files for the API and web views, allowing a clear separation between accessing data via the API and presenting data via web views. This organisation facilitates code management and maintenance by distinguishing between paths that serve JSON data and paths that present HTML views.

API routes are defined only in the `Posts` application to centralise the management of resources related to posts and their comments. By not having its own `urls.py` file in the `Comments` application, redundancy is reduced and the project structure is simplified by grouping all related API paths in one place. This makes it easier to understand the data flow and the interrelationship between posts and comments, promoting a more coherent and maintainable architecture, and the correct use of REST best practices.

**URLs API REST:**

* **In the archive:**`/my_project_blog/apps/posts/urls/api_urls.py` :
    

```python
from django.urls import path
from ..views.api_views import PostListCreateAPIView, PostRetrieveUpdateDestroyAPIView
from ...comments.views.api_views import (
    CommentListCreateAPIView,
    CommentRetrieveUpdateDestroyAPIView,
)

urlpatterns = [
    # Route for listing all posts or creating a new post
    path("", PostListCreateAPIView.as_view(), name="post-list-create"),
    # Route for retrieving, updating, or deleting a specific post by post_id
    path(
        "<int:post_id>/",
        PostRetrieveUpdateDestroyAPIView.as_view(),
        name="post-retrieve-update-destroy",
    ),
    # Route for listing all comments for a specific post or creating a new comment for that post
    path(
        "<int:post_id>/comments/",
        CommentListCreateAPIView.as_view(),
        name="post-comment-create",
    ),
    # Route for retrieving, updating, or deleting a specific comment by comment_pk for a specific post
    path(
        "<int:post_id>/comments/<int:comment_pk>/",
        CommentRetrieveUpdateDestroyAPIView.as_view(),
        name="post-comment-retrieve-update-destroy",
    ),
]
```

**URLs web:**

* **In the archive:**`/my_project_blog/apps/posts/urls/web_urls.py` :
    

```python
from django.urls import path
from ..views.web_views import PostListView, PostDetailView
from ...comments.views.web_views import CommentListView, CommentDetailView

urlpatterns = [
    # Route for listing all posts.
    # The URL is "web/posts/", and it maps to PostListView to display a list of all posts.
    path("", PostListView.as_view(), name="post-list"),
    # Route for displaying details of a specific post identified by post_id.
    # The URL is "web/posts/<post_id>/", and it maps to PostDetailView to display details of a single post.
    path("<int:post_id>/", PostDetailView.as_view(), name="post-detail"),
    # Route for listing all comments for a specific post identified by post_id.
    # The URL is "web/posts/<post_id>/comments", and it maps to CommentListView to display a list of comments for the given post.
    path(
        "<int:post_id>/comments",
        CommentListView.as_view(),
        name="post-comments",
    ),
    # Route for displaying details of a specific comment identified by comment_id for a specific post.
    # The URL is "web/posts/<post_id>/comments/<comment_id>/", and it maps to CommentDetailView to display details of a single comment.
    path(
        "<int:post_id>/comments/<int:comment_id>/",
        CommentDetailView.as_view(),
        name="post-comment-detail",
    ),
]
```

**General project URLs:**

* **In the archive:**`/my_project_blog/my_project_blog/urls.py` :
    

```python
from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path("admin/", admin.site.urls),
    path("posts/", include("apps.posts.urls.web_urls")),
    path("api/posts/", include("apps.posts.urls.api_urls")),
]
```

---

## Web application and API testing

Now, in the third section of this blog, we will create some posts and add several comments to each of the posts to verify the correct functioning of the web application and the API and web URLs.

1. ### Execute the project
    
    \- **Creates Migrations:**
    
    ```bash
    python manage.py makemigrations
    ```
    
    \- **Apply migrations:**
    
    ```bash
    python manage.py migrate
    ```
    
    \- **Run the Django development server:**
    
    ```bash
    python manage.py runserver
    ```
    
    ***<mark>Note:</mark>*** Open your browser and navigate to `http://127.0.0.1:8000/`, from now on the urls that I will give you will be after the domain (in this case our `localhost`), example: If I give you the url `/api/posts/`, in the browser you will have to put `http://127.0.0.1:8000/api/posts/`.
    
2. **Creation of posts**
    
    1. **Access the Django REST API interface:**
        
        * **URL:**`/api/posts/`
            
        * **Action:** Fill in the form with the details of the post to be created and click on the "POST" button.
            
    
    
![api posts image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l0v9rwhcrmjn7k2s6gki.png)


    
3. ### **Add comments to posts:**
    
    1. **Access the Django REST API interface:**
        
        * **URL:**`/api/posts/{post_id}/comments/`
            
        * **Action:** Fill in the form with the details of the comment to be created for a specific post and click on the "POST" button.
            
    
    
![api comments image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6gqhowi38zuf5xwosva4.png)


    
    You can repeat these steps to create as many posts and comments as you want.
    
    Also, in this same Django REST API interface you can edit posts or comments or delete them.
    
4. ### Verify the creation of posts and comments:
    

Having already created several posts and comments for some of these via the REST API, we can see these in the web URLs that interact with the HTML templates.

So that when you enter the given URLs you can see the same design, you can see the HTML code of each template in the HTML files of the project.

[**Full project code on GitHub**](https://github.com/MateoRamirezRubio1/mini-blog-rest-api): [*<mark>Click</mark>*](https://github.com/MateoRamirezRubio1/mini-blog-rest-api).

1. 1. **See the list of posts:**
        
        * **URL:**`/posts/`
            
        
        
![posts list image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yktt5nnper0mip5aifmq.png)


        
    2. **See the details of a specific post:**
        
        * **URL:**`/posts/{post_id}/`
            
        
        
![details post image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/peocz2ej5fwtrga8830i.png)


        
    3. **See comments on a specific post:**
        
        * **URL:**`/posts/{post_id}/comments/`
            
        
        
![comments post image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bwanjg9wsywmrlndwbe5.png)


        
    4. **View the details of a comment on a specific post:**
        
        * **URL:**`/posts/{post_id}/comments/{comment_id}/`
            
        
        
![detail comments image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/szguhyzhtlh0kmmic1m5.png)


        

---

## Conclusions

### Benefits of the Services and Repositories Employer

1. **Separation of Responsibilities:**
    
    Separation of responsibilities is one of the fundamental principles in software design. In the `Services` and `Repositories` pattern, we clearly separate data access concerns (repositories) from business logic (services).
    
    **Benefits:**
    
    * **Clarity and Organisation:** The code is organised so that each class and function has a single, clearly defined responsibility. This makes the code easier to understand and maintain.
        
    * **Maintainability:** When the business logic changes, only the services need to be modified, while the repositories remain unchanged. This reduces the number of changes and the risk of introducing errors.
        
    * **Team Collaboration:** In a development team, different members can work at different layers (e.g. one on services and one on repositories) without interfering with each other, facilitating collaboration and integration.
        
2. **Re-use of the Code:**
    
    The pattern encourages code reuse by centralising business logic and data access in specific classes. This avoids code duplication and facilitates code reuse in different parts of the application.
    
    Benefits:
    
    * **Duplication Reduction:** By having business logic in services and data access in repositories, we avoid repeating code in multiple places, making the code more DRY (Don't Repeat Yourself).
        
    * **Consistency:** Reusing the same code in different parts of the application ensures that the same logic and rules are followed everywhere, which increases consistency and reduces errors.
        
    * **Ease of Update:** If you need to change the way data is accessed or business logic is implemented, you only need to update the corresponding repository or service. The other parts of the application that depend on them will automatically benefit from the changes.
        
3. **Ease of Testing:**
    
    The separation of business logic and data access logic facilitates the creation of unit and integration tests. Services and repositories can be tested in isolation, which simplifies the testing process.
    
    Benefits:
    
    * **Unit testing:** By having business logic in services and data access in repositories, it is easier to create unit tests for each component independently. This makes it possible to quickly detect errors and ensure that each part works correctly.
        
    * **Mocks and Stubs:** During testing, it is easy to use mocks and stubs to simulate the behaviour of repositories or services. This allows testing business logic without relying on the database or other external services.
        
    * **Reduced Testing Complexity:** By having clear and well-defined responsibilities, testing becomes less complex and more specific. This improves test coverage and software reliability.
        
4. **Maintainability and Extensibility:**
    
    The `Services` and `Repositories` pattern makes code more maintainable and extensible. This is especially important in long-term projects, where requirements may change over time.
    
    **Benefits:**
    
    * **Code Evolution:** When you need to add new functionality, it is easy to extend existing services and repositories without affecting the rest of the application. This allows the code to evolve in a controlled and safe way.
        
    * **Easy Refactoring:** If you identify an improvement in the code structure or business logic implementation, it is easy to refactor services and repositories without great risk. The separation of responsibilities makes it easy to identify which parts of the code need to be changed.
        
    * **Adaptability to New Technologies:** If at some point you decide to change the persistence technology (for example, from a SQL database to a NoSQL one), you only need to modify the repositories without affecting the business logic implemented in the services.
        

---

Finally, in closing, I thank you for your time and attention in following this guide to the Services and Repositories design pattern in a Django project with the Django REST Framework. I hope this detailed explanation has given you a solid understanding of how to structure your applications in an efficient and maintainable way.

Implementing this pattern will not only improve the organization of your code, but also facilitate its evolution and scalability as your project grows. If you have any additional questions or opinions on the topic, feel free to post in the comments, they are left open for discussion.

Good luck with your development and best of luck with your future projects!

See you next time!