TechTask_API

1. Introduction / Project Overview

TechTask_API is a secure, multi-layered web application built with .NET 9 Web API designed for managing software development projects through a structured system of Projects, Sprints, and Tasks.

The system provides role-based access and workflow management for:

• Project Managers (PMs) — responsible for creating and managing projects, sprints, and tasks.
• Developers (DEVs) — responsible for viewing and updating assigned tasks.

The main goal of TechTask_API is to offer a maintainable, scalable, and secure backend solution that enforces business rules, authentication, and separation of concerns following clean architectural principles.

---

2. Architecture and Design

Layered Architecture

The project follows a Clean Layered Architecture with four independent layers:

1. API (TechTask_API) – Presentation layer exposing endpoints and managing requests/responses.
2. BLL (TechTask.BLL) – Business Logic Layer containing rules, validation, and workflows.
3. Core (TechTask.Core) – Shared definitions such as DTOs, Enums, and abstractions.
4. DAL (TechTask.DAL) – Data Access Layer using Entity Framework Core for database interaction.

This architecture ensures modularity, testability, and separation of concerns.

---

Dependency Flow

API → BLL → DAL ↔ Database
       ↑
     Core

• The API communicates only with BLL.
• BLL interacts with DAL for persistence.
• Core defines shared contracts and DTOs used across layers.
• The DAL handles EF Core mappings and context management.

---

SOLID Principles Applied

• S – Single Responsibility: Each service and controller has one purpose.
• O – Open/Closed Principle: Functionality can be extended without modifying existing code.
• D – Dependency Inversion: High-level modules depend on abstractions, not implementations.

---

Dependency Injection

Dependency Injection (DI) ensures all services and the database context are managed efficiently.

Example in Program.cs:

builder.Services.AddScoped<UserService>();
builder.Services.AddScoped<ProjectService>();
builder.Services.AddScoped<SprintService>();
builder.Services.AddScoped<TaskService>();

The DbContext is configured as:

builder.Services.AddDbContext<TechTasksDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

Using Scoped lifetime guarantees each HTTP request gets its own database context instance, preventing concurrency issues.

---

Why Not Singleton?

Singleton services are avoided for any component that manages data or state (like DbContext).
Using Singleton for EF Core would:

• Cause shared state across requests (unsafe concurrency).
• Break transaction boundaries.
• Lead to connection pool exhaustion.

Singleton is reserved for stateless services, like configuration helpers or the JWT generator.

---

Use of DTOs

DTOs are implemented to decouple internal EF Core entities from exposed API models, ensuring:

• Data abstraction and security (no password exposure).
• Clean serialization in API responses.
• Layer isolation between BLL and API.

Example:

public class UserDTO
{
    public int Id { get; set; }
    public string UserName { get; set; } = "";
    public string Email { get; set; } = "";
    public string Role { get; set; } = "";
}

---

3. Project Structure

TechTask_API.sln
│
├── TechTask_API/                # Presentation Layer (Controllers, Program.cs)
│   ├── Controllers/
│   │   ├── UsersController.cs
│   │   ├── ProjectsController.cs
│   │   ├── SprintsController.cs
│   │   └── TasksController.cs
│   ├── appsettings.json
│   └── Program.cs
│
├── TechTask.BLL/                # Business Logic Layer
│   ├── Services/
│   │   ├── UserService.cs
│   │   ├── ProjectService.cs
│   │   ├── SprintService.cs
│   │   └── TaskService.cs
│   └── Auth/
│       └── JwtService.cs
│
├── TechTask.Core/               # Core Layer
│   ├── DTOs/
│   │   ├── UserDTOs.cs
│   │   ├── ProjectDTOs.cs
│   │   ├── SprintDTOs.cs
│   │   └── TaskDTOs.cs
│   └── Enums/
│
└── TechTask.DAL/                # Data Access Layer
    ├── Entities/
    │   ├── User.cs
    │   ├── Project.cs
    │   ├── Sprint.cs
    │   └── Task.cs
    └── TechTasksDbContext.cs

---

4. Implemented Features

• .NET 9 Web API foundation.
• Entity Framework Core (SQL Server 2022) integration.
• JWT Authentication with role-based access control.
• BCrypt for password hashing.
• Swagger UI for API documentation and live testing.
• Dependency Injection for all services and the DbContext.
• CRUD operations for:
  • Users
  • Projects
  • Sprints
  • Tasks

---

5. Authentication and Security

JWT Authentication

Implemented through:

• JwtService class for token generation.
• Authentication middleware in Program.cs.

JWT is generated upon login and must be provided in requests to protected endpoints.

Example configuration in appsettings.json:

"Jwt": {
  "Key": "SuperSecretPrivateKey123!",
  "Issuer": "TechTask_API",
  "Audience": "TechTask_Users"
}

Example of token use in Swagger:

Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

---

Swagger Authorization Setup

The API includes Swagger JWT configuration:

c.AddSecurityDefinition("Bearer", new OpenApiSecurityScheme
{
    Description = "Enter 'Bearer' followed by your token.",
    Name = "Authorization",
    In = ParameterLocation.Header,
    Type = SecuritySchemeType.ApiKey,
    Scheme = "Bearer"
});

This enables the Authorize button in Swagger UI, allowing users to test endpoints securely.

---

Token Validation

The middleware validates:

• Signature and expiration.
• Issuer and audience.
• Role claims for authorization.

Example protected controller:

[Authorize(Roles = "PM")]
[HttpPost("create")]
public async Task<IActionResult> CreateProject(ProjectCreateDTO dto)
{
    var result = await _projectService.CreateAsync(dto);
    return result.Success ? Ok(result.Data) : BadRequest(result.Message);
}

---

6. Business Rules

Users

• Unique UserName and Email.
• Passwords stored using BCrypt.
• Role restricted to PM or DEV.
• PM deletion leaves projects unassigned.
• DEV deletion sets tasks to NULL.

Projects

• Created only by PMs.
• Unique Title per PM.
• Cannot delete a project with existing sprints.

Sprints

• Must belong to a valid project.
• Start date < End date.
• No duplicate sprint names per project.

Tasks

• Optional assignment to a developer.
• Only PMs can create/delete.
• DEVs can only update task states.
• Completed tasks cannot revert.

---

7. Technical Best Practices

Practice	Description
Clean Layered Architecture	Separation of concerns between presentation, logic, and data layers.
SOLID Principles	Ensures extensibility, modularity, and maintainability.
Dependency Injection	Improves testing and decouples dependencies.
Scoped DbContext	Prevents concurrency issues per HTTP request.
DTOs	Provides abstraction between internal entities and exposed models.
JWT Authorization	Adds secure, stateless access control.
Swagger Integration	Facilitates documentation and real-time testing.

---

8. Installation and Setup

Prerequisites

• .NET SDK 9.0
• SQL Server 2022
• Visual Studio 2022 or Visual Studio Code

Setup Steps

1. Clone the repository:

   git clone https://github.com/<your-username>/TechTask_API.git
   cd TechTask_API

2. Restore dependencies:

   dotnet restore

3. Update appsettings.json connection string:

   "ConnectionStrings": {
     "DefaultConnection": "Server=localhost;Database=TechTasksDB;Trusted_Connection=True;TrustServerCertificate=True;"
   }

4. Build the project:

   dotnet build

5. Run the API:

   dotnet run --project TechTask_API

---

9. Running and Testing

• API URL:

  http://localhost:5233
  

• Swagger UI:

  https://localhost:7082/swagger
  

Example – Login

POST /api/users/login

{
  "email": "example@gmail.com",
  "password": "1234"
}

Response:

{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

Use this token for subsequent authorized requests.

10. Conclusion

TechTask_API is a secure, scalable backend for managing software projects through clean architecture, layered design, and JWT-based authentication.
Its structure enables long-term maintainability, testability, and future expansion — ideal for enterprise-level backend development.