CrmApp — Desktop CRM

§ 01 Problem

Businesses lose track of who talked to which customer and when — calls, meetings and emails end up scattered across inboxes and spreadsheets, and a dropping satisfaction signal goes unnoticed until the customer is gone. The course brief asked for a real OOP application; I chose to answer it with a centralized customer-tracking system where every interaction lives in one place.

§ 02 Approach

• Strict three-layer separation: Forms/ only talks to the user, Data/ owns every line of SQL, Models/ holds plain entities with enums for type-safe status and activity types — so a change in one layer doesn't ripple through the others.
• A generic abstract BaseRepository<T> forces every entity repository to implement Add, GetAll, GetById, Update, Delete — inheritance, generics and abstraction doing actual work instead of living on a slide.
• Every query is parametrized ADO.NET — CustomerRepository.cs binds @firstName, @email and friends via parameters, never string concatenation — which is the habit that matters long after the course grade.
• Zero-setup persistence: DatabaseHelper.cs creates crm.db on first launch, builds the schema with foreign keys (Company 1-N Customer 1-N Activity), and loads a deterministic seed (30 companies, ~400 customers, ~600 activities) so the app demos itself.
• The UI takes itself seriously for a course project: required-field checks with MailAddress-based email verification, live search plus status/company filters, and a single DesignSystem.cs so every screen shares one palette and type scale.

§ 03 Outcome

A working desktop CRM with a dashboard (status distribution bars, last-10-activities feed), full CRUD across three modules, and activity notes that surface satisfaction signals like low-satisfaction escalation flags. Presented as my NTP-2 term project in May 2026 — the deck walks from problem to UML to running screens.

§ 04 For the record

§ 05 Evidence

∎