Skip to main content

​
Purpose

The entity layer (InapescaWeb.Entidades namespace) provides Plain Old CLR Objects (POCOs) that serve as data transfer objects throughout the SMAF system. These entities represent the core business domain of expense and travel management in the Mexican Federal Public Administration.

​
Architecture

​
POCO Pattern

All entity classes follow the Plain Old CLR Object (POCO) pattern:
  • Simple C# classes with no framework dependencies
  • Private fields with public property accessors
  • Parameterless constructors for easy instantiation
  • Serializable for data transfer and persistence
public class Comision
{
    private string lsFolio;
    private string lsFechaSol;
    
    public string Folio
    {
        get { return lsFolio; }
        set { lsFolio = value; }
    }
    
    public string Fecha_Solicitud
    {
        get { return lsFechaSol; }
        set { lsFechaSol = value; }
    }
}

​
Data Transfer Objects

Entities function as DTOs to:
  • Transfer data between application layers
  • Serialize/deserialize JSON and XML for web services
  • Map to database records via data access layer
  • Bind to UI controls in web forms

​
Core Entity Categories

​
Travel Management Entities

Comision

Travel assignment requests with approval workflow, transportation, lodging, and budget allocation

Itinerario

Flight itinerary details including airlines, flight numbers, dates, and passenger information

​
Expense Verification Entities

DatosComprobacion

Comprehensive expense verification data with totals for advance and accrued expenses

comprobacion

Individual expense proof records with dates, concepts, amounts, and observations

​
User and Organization Entities

Usuario

User authentication, profile information, roles, and organizational assignment

Ubicacion

Organizational unit details including address, contact information, and hierarchy

​
Resource Management Entities

Transporte

Vehicle and transportation resource catalog with classes, types, and availability status

ComisionDetalle

Detailed commission records with financial breakdowns by expense category

​
Field Naming Conventions

​
Hungarian Notation

Private fields use Hungarian notation prefixes:
  • ls = Local String (e.g., lsFolio, lsNombre)
  • pd = Private Double (e.g., pdTotalComprobado)
  • _ls = Local String with underscore (e.g., _lsUbicacion)

​
Property Naming

Public properties use descriptive Spanish names:
  • Fecha_Solicitud = Request Date
  • Total_Viaticos = Total Per Diem
  • Ubicacion_Comisionado = Assignee Location
  • Partida_Presupuestal = Budget Line Item

​
Data Types

​
String-Based Architecture

Most properties use string type for flexibility: 
public string Fecha_Inicio { get; set; }  // Date as string
public string Total_Viaticos { get; set; }  // Amount as string
public string Dias_Total { get; set; }  // Number as string
String-based dates and numbers require validation and conversion in the business logic layer.

​
Numeric Properties

Financial calculations use double for precision: 
public double TotalComprobado { get; set; }
public double TotalViaticosAnt { get; set; }
public double GranTotal { get; set; }

​
Initialization Patterns

​
Default Constructors

Entities initialize fields to safe default values: 
public Usuario()
{
    lsUsuario = string.Empty;
    lsPassword = string.Empty;
    lsNivel = string.Empty;
    lsRFC = string.Empty;
}

​
Numeric Initialization

Financial entities initialize numeric fields to zero: 
public DatosComprobacion()
{
    pdTotalComprobado = 0;
    pdTotalViaticosAnt = 0;
    pdGranTotal = 0;
}

​
Serialization Support

​
JSON Serialization

Entities serialize cleanly to JSON for REST APIs: 
{
  "Folio": "2024-001",
  "Fecha_Solicitud": "2024-03-15",
  "Usuario_Solicita": "juan.lopez",
  "Total_Viaticos": "5000.00"
}

​
XML Support

Specialized entities like cfdv33, cfdv4, cfdiv33, and cfdiv4 handle CFDI (Comprobante Fiscal Digital por Internet) XML invoice formats mandated by Mexican tax regulations.

Data Access Layer

How entities map to database operations

Business Logic Layer

Entity validation and business rules

API Layer

Entity serialization in web services

Database Schema

Entity-to-table mappings

​
Best Practices

1

Always initialize entities

Use parameterless constructors to ensure fields have safe default values
2

Validate before persistence

Check required fields and data formats in the business logic layer
3

Convert data types carefully

When converting string dates/numbers, handle parsing errors gracefully
4

Document Spanish terminology

Include comments explaining business domain terms for non-Spanish speakers

Build docs developers (and LLMs) love

Get started for freeTalk to us