Caso de estudio · 2026
VitalPet
Plataforma de gestión veterinaria
Plataforma web para centralizar la operación de una veterinaria: clientes, mascotas, historia clínica, turnos, inventario y ventas. Proyecto académico en equipo de tres, con arquitectura de cinco capas y el acceso resuelto en el servidor.
- ASP.NET
- C#
- SQL Server
- ADO.NET
- .NET Framework 4.8.1
- Git
- Rol
- Desarrollo .NET en equipo de tres: capas, seguridad, auditoría y dígitos verificadores
- Alcance
- 5 capas · 3 roles · 9 pantallas implementadas
- Interfaz
- ASP.NET Web Forms sobre .NET Framework 4.8.1
- Base de datos
- SQL Server con ADO.NET conectado y desconectado, bitácora y backup
Contexto
Qué es y de dónde salió.
VitalPet concentra en un solo sistema lo que en la veterinaria vivía repartido entre planillas y registros manuales: el alta de clientes y mascotas, la historia clínica, la agenda de turnos, el stock de medicamentos y productos, y la facturación de las ventas.
Fue el trabajo final de la materia Desarrollo y Arquitecturas Web, en un equipo de tres. El diseño cubrió la plataforma completa —pantallas, modelo de datos, casos de uso, un modelo de permisos por patente, familia y perfil, y las políticas de seguridad—; la entrega implementada se concentró en el núcleo de acceso y administración: autenticación, usuarios, mascotas, auditoría, backup y control de integridad.
Se construyó con ASP.NET Web Forms sobre .NET Framework 4.8.1, C#, ADO.NET y SQL Server, y se versionó con Git bajo el modelo Git Flow.
Alcance
Los procesos que cubre el sistema y los roles que los ejecutan.
Procesos
Acceso y administración de usuarios
Registro con validación de DNI y contraseña fuerte, bloqueo de la cuenta a los tres intentos fallidos, alta y edición de usuarios por rol, y cambio de contraseña.
Gestión de mascotas
Alta de mascotas con especie, raza y fecha de nacimiento, asociadas al cliente que las registra.
Integridad de los datos
Dígitos verificadores horizontales por registro y verticales por tabla. Si la verificación falla, el sistema entra en modo mantenimiento hasta que se repare.
Auditoría y continuidad
Bitácora de eventos con módulo, evento y criticidad; backup y restore de la base desde la propia aplicación; verificación y reparación de los dígitos.
Roles
-
Cliente
Registra sus mascotas y cambia su contraseña.
-
Administrador
Gestiona usuarios y consulta la bitácora de eventos.
-
Web Master
Ejecuta backup y restore, y administra los dígitos verificadores.
Arquitectura
Cinco capas, una responsabilidad cada una.
- Interfaz GUI
Páginas ASP.NET Web Forms sobre un Master Page común. Capturan datos, muestran resultados y navegan; nunca ejecutan SQL.
- Entidades BE
Objetos del negocio (usuario, mascota, evento) que viajan entre capas y se construyen desde un DataRow.
- Negocio BLL
Validaciones, reglas de acceso, bloqueo por intentos, dígitos verificadores y registro de eventos.
- Datos DAL
ADO.NET contra SQL Server, con una clase base que toma la cadena de conexión de Web.config.
- Servicios Servicios
Lo transversal: sesión, hash y encriptación, y utilidades compartidas.
La interfaz no conoce SQL y la capa de datos no conoce reglas de negocio: cada capa recibe y devuelve entidades. Esa separación permitió escribir la seguridad una sola vez —en el login, el ticket y Web.config— y aplicarla en todas las pantallas.
Decisiones
Las cinco que definieron el sistema.
Un rol en el ticket, la autorización en Web.config
El login valida el hash, bloquea la cuenta a los tres intentos y, ya dentro, el sistema emite un ticket de Forms Authentication con el rol del usuario. En cada petición, Global.asax reconstruye el principal con ese rol y Web.config decide qué páginas lo admiten. Forzar la URL devuelve acceso denegado antes de que la página se cargue.
Dos cifrados para dos problemas distintos
Las contraseñas se guardan con SHA-256, un hash irreversible. Los datos personales —nombre, apellido, usuario y mail— se cifran con AES reversible, porque la aplicación necesita mostrarlos. La capa de datos descifra al leer y cifra al escribir, así que el resto del sistema trabaja con texto plano.
Dígitos verificadores en dos direcciones
Cada fila guarda un dígito horizontal calculado a partir de sus campos; cada tabla guarda uno vertical en una tabla de control. Si un registro se altera por fuera de la aplicación, el recálculo lo detecta, identifica la tabla y el sistema queda en mantenimiento hasta que un Web Master lo repare desde DV_Form.
Conectado o desconectado, según la operación
Las lecturas cortas y las validaciones usan SqlCommand y lectores con la conexión abierta; los listados y los ABM usan SqlDataAdapter y DataTable para trabajar en memoria y liberar la conexión temprano. La misma capa de datos combina los dos modelos de ADO.NET.
La auditoría como parte del flujo
Iniciar sesión o registrar un usuario deja un evento con módulo, fecha, usuario y criticidad. La bitácora se consulta desde la aplicación, con filtros por usuario, fecha, módulo, evento y criticidad.
Resultado
Qué quedó entregado y funcionando.
- Autenticación con hash SHA-256, bloqueo a los tres intentos y contraseñas validadas por longitud, mayúsculas, números y símbolos.
- Autorización por rol a nivel de página con Forms Authentication, Global.asax y Web.config.
- Alta de mascotas y administración de usuarios, con los datos personales cifrados en AES.
- Dígitos verificadores horizontales y verticales, con pantalla de verificación y reparación para el Web Master.
- Bitácora de eventos y backup y restore de la base desde la propia aplicación.
La entrega reúne las cinco capas y las nueve pantallas del sistema. Lo que haría distinto hoy: mover la clave de cifrado fuera del código y agregar sal al hash de las contraseñas.