Case study · 2026
VitalPet
Veterinary clinic management platform
Web platform to centralise a veterinary clinic operation: clients, pets, clinical history, appointments, inventory and sales. A three-person academic project with a five-layer architecture and access control enforced on the server.
- ASP.NET
- C#
- SQL Server
- ADO.NET
- .NET Framework 4.8.1
- Git
- Role
- .NET development in a three-person team: layers, security, auditing and check digits
- Scope
- 5 layers · 3 roles · 9 implemented screens
- Interface
- ASP.NET Web Forms on .NET Framework 4.8.1
- Database
- SQL Server with connected and disconnected ADO.NET, event log and backup
Context
What it is and where it came from.
VitalPet brings into one system what used to live across spreadsheets and paper records: client and pet registration, clinical history, the appointment schedule, stock of medicines and products, and sales invoicing.
It was the final project for the Web Development and Architectures course, in a team of three. The design covered the whole platform —screens, data model, use cases, a permission model based on patente, familia and perfil, and the security policies—; the delivered build focused on the access and administration core: authentication, users, pets, auditing, backup and integrity control.
It was built with ASP.NET Web Forms on .NET Framework 4.8.1, C#, ADO.NET and SQL Server, and versioned with Git following Git Flow.
Scope
The processes the system covers and the roles that run them.
Processes
Access and user management
Registration with DNI validation and strong-password rules, account lockout after three failed attempts, user creation and editing by role, and password change.
Pet management
Pet registration with species, breed and date of birth, linked to the client who registers it.
Data integrity
Horizontal check digits per record and vertical ones per table. If verification fails, the system enters maintenance mode until it is repaired.
Auditing and continuity
Event log with module, event and criticality; database backup and restore from inside the application; check-digit verification and repair.
Roles
-
Client
Registers their pets and changes their password.
-
Administrator
Manages users and reads the event log.
-
Web Master
Runs backup and restore, and manages the check digits.
Architecture
Five layers, one responsibility each.
- Presentation GUI
ASP.NET Web Forms pages over a shared Master Page. They capture input, render results and navigate; they never run SQL.
- Entities BE
Business objects (user, pet, event) that travel between layers and are built from a DataRow.
- Business BLL
Validation, access rules, attempt lockout, check digits and event logging.
- Data DAL
ADO.NET against SQL Server, with a base class that reads the connection string from Web.config.
- Services Services
Cross-cutting concerns: session, hashing and encryption, and shared helpers.
The interface knows nothing about SQL and the data layer knows nothing about business rules: each layer takes and returns entities. That separation let us write security once —in the login, the ticket and Web.config— and apply it to every screen.
Decisions
The five that shaped the system.
A role in the ticket, authorisation in Web.config
The login checks the hash, locks the account after three failed attempts and, once inside, the system issues a Forms Authentication ticket carrying the user role. On every request, Global.asax rebuilds the principal with that role and Web.config decides which pages accept it. Forcing a URL returns access denied before the page ever loads.
Two ciphers for two different problems
Passwords are stored with SHA-256, an irreversible hash. Personal data —first name, last name, username and email— is encrypted with reversible AES, because the application needs to display it. The data layer decrypts on read and encrypts on write, so the rest of the system works with plain text.
Check digits in two directions
Every row stores a horizontal check digit computed from its fields; every table stores a vertical one in a control table. If a record is changed outside the application, recomputation detects it, identifies the table and leaves the system in maintenance mode until a Web Master repairs it from DV_Form.
Connected or disconnected, depending on the operation
Short reads and validations use SqlCommand and readers with the connection open; listings and CRUD operations use SqlDataAdapter and DataTable to work in memory and release the connection early. The same data layer combines both ADO.NET models.
Auditing as part of the flow
Signing in or registering a user leaves an event with module, date, user and criticality. The log is queried from the application itself, filtered by user, date, module, event and criticality.
Outcome
What was delivered and working.
- Authentication with SHA-256 hashing, lockout after three attempts, and passwords validated for length, upper case, numbers and symbols.
- Page-level role authorisation with Forms Authentication, Global.asax and Web.config.
- Pet registration and user administration, with personal data encrypted in AES.
- Horizontal and vertical check digits, with a verification and repair screen for the Web Master.
- Event log and database backup and restore from inside the application.
The delivery brings together the five layers and the nine screens of the system. What I would do differently today: move the encryption key out of the code and add a salt to the password hash.