Skip to main content

Overview

The IRepositorioPosicion interface and RepositorioPosicion implementation provide data access operations for managing player positions (e.g., Delantero, Defensa, Mediocampista, Portero). Positions are associated with players (Jugadores) in the system.

Interface Definition

IRepositorioPosicion.cs

Implementation

RepositorioPosicion.cs

Methods Reference

AddPosicion

Adds a new position to the database.
Posicion
required
The Posicion entity to add
Posicion
The inserted Posicion entity with its generated ID
Implementation (Lines 8-13)
Usage Example:

GetAllPosiciones

Retrieves all positions with their associated players.
IEnumerable<Posicion>
Collection of all Posicion entities with eagerly loaded Jugadores
Exception
Throws exception with message “Posiciones not found” if the result is null
Implementation (Lines 14-26)
Key Features:
  • Uses .Include(p => p.Jugadores) to eagerly load all players in each position
  • Uses .AsNoTracking() for improved read performance
  • Throws exception if no positions exist
Usage Example:

GetPosicion

Retrieves a specific position by ID.
int
required
The ID of the position to retrieve
Posicion
The Posicion entity
Exception
Throws exception with message “Posicion not found” if the ID doesn’t exist
Implementation (Lines 27-31)
Usage Example:

UpdatePosicion

Updates an existing position’s information.
Posicion
required
The Posicion entity with updated values (must include valid Id)
Posicion
The updated Posicion entity
Exception
Throws exception with message “Posicion not found” if the ID doesn’t exist
Implementation (Lines 33-40)
Updated Properties:
  • Nombre - Position name
Usage Example:

DeletePosicion

Deletes a position from the database.
int
required
The ID of the position to delete
Posicion
The deleted Posicion entity
Exception
Throws exception with message “Posicion not found” if the ID doesn’t exist
Implementation (Lines 42-57)
Deleting a position will fail if it has associated players due to foreign key constraints configured with DeleteBehavior.Restrict. Remove all players from the position before deleting, or reassign them to different positions.
Usage Example:

validateDuplicates

Validates whether a position name already exists in the database.
Posicion
required
The Posicion entity to validate
bool
true if a duplicate position name exists (different ID with same name), false otherwise
Implementation (Lines 59-84)
Validation Logic:
  1. Case-insensitive comparison using .ToLower()
  2. Trims whitespace from input
  3. Excludes current position when updating (checks posicionIngresada.Id != posicion.Id)
  4. Returns false on any exception
Usage Example:

Dependency Injection

Register the repository in Program.cs:
Program.cs (Line 20)
Inject into controllers:

Common Workflows

Posicion Entity

Domain model for positions

Jugador Repository

Players assigned to positions

Standard Football Positions

Portero

Goalkeeper position

Defensa

Defender position

Mediocampista

Midfielder position

Delantero

Forward/Striker position

Error Handling

Multiple methods throw exceptions when entities are not found:
  • GetAllPosiciones - throws if no positions exist
  • GetPosicion - throws if position not found
  • UpdatePosicion - throws if position not found (via GetPosicion)
  • DeletePosicion - throws if position not found (via GetPosicion)
Always use try-catch blocks when calling these methods.

Foreign Key Constraints

Cascade Delete Restriction:The DataContext configures all foreign keys with DeleteBehavior.Restrict. This means:
  • You cannot delete a position that has associated players
  • You must first remove or reassign all players before deleting the position
  • This prevents accidental data loss and maintains referential integrity
DataContext.cs (Lines 37-40)

Performance Considerations

Optimization Tips:
  • GetAllPosiciones() uses .AsNoTracking() for improved read performance
  • The .Include(p => p.Jugadores) eagerly loads all players - omit if not needed
  • validateDuplicates() calls GetAllPosiciones(), which may be inefficient for large datasets
  • Consider implementing indexed queries for duplicate validation in production

Business Rules

Position names must be unique (case-insensitive). The validateDuplicates method enforces this rule before creating or updating positions.
Positions cannot be deleted if they have associated players. This ensures data consistency and prevents orphaned player records.
Position names are trimmed during validation to prevent duplicates caused by leading/trailing whitespace.
While not enforced at the database level, applications typically use standard football positions:
  • Portero (Goalkeeper)
  • Defensa (Defender)
  • Mediocampista/Centrocampista (Midfielder)
  • Delantero (Forward/Striker)

Usage Statistics