taylorleprechaun/cardcollector

Purpose and Entry Points

Card Collector is a personal Yu-Gi-Oh collection and purchase-planning system built as an ASP.NET Core Razor Pages application. HTTP startup, dependency wiring, authentication, EF Core setup, and hosted work begin in Program.cs. Feature endpoints are PageModels paired with server-rendered Razor views, e.g. Pages/Collection.cshtml.cs, Pages/Wishlist.cshtml.cs, and Pages/Stats.cshtml.cs.

Presentation and Interaction Layer

Razor Pages own request handling, form actions, redirects, CSV downloads, and page-specific view-model assembly. Shared partials provide reusable result tables and modals. Browser-side JavaScript augments selected workflows rather than serving as a separate frontend.

• Pages/Browse.cshtml.cs

• Pages/Cart.cshtml.cs

• Pages/Shared/_Layout.cshtml

• wwwroot/js/cart.js

Application Orchestration

CardService is the primary domain-facing read/orchestration layer. It joins cached card catalog data with persisted collection state to produce browsing, collection, wishlist, dashboard, audit, new-printing, and purchase-priority views. PageModels should cross this boundary through ICardService, rather than directly composing catalog and collection data.

• Services/CardService.cs

• Services/ICardService.cs

• Services/PurchasePriorityAnalyzer.cs

Catalog Ingestion and External Data Boundary

Card catalog metadata is represented by DTOs and loaded via a repository/cache boundary. Startup or cache refresh obtains yaml-yugi card/set data; image metadata comes from YGO Pro Deck, while images remain CDN-hosted. Cache behavior supports TTLs and stale-data fallback; Speed Duel sets are filtered during load.

• Repository/CardDataRepository.cs

• Repository/CardDataMapper.cs

• Data/FileCacheHelper.cs

• DTO/YamlYugi/YamlCard.cs

Persistence and Transaction Boundary

EF Core maps local SQLite state through AppDbContext. Repositories isolate entity-specific queries and mutations; UnitOfWork provides the commit boundary. Persisted state covers owned entries, preferred printings, cart/pending orders, checkouts, ignored/dismissed cards, and historical value snapshots.

• Data/AppDbContext.cs

• Repository/UnitOfWork.cs

• Repository/CollectionRepository.cs

• Data/Models/CollectionEntry.cs

Collection-to-Purchase Lifecycle

Users select preferred versions, which drive wishlist and buy-list candidates. Wishlist items can be staged as pending order lines, finalized through Cart into Orders, then received into the collection. Ownership, pending orders, and checkout state influence visibility and badges throughout shopping and collection workflows.

• Pages/Wishlist.cshtml.cs

• Pages/BuyList.cshtml.cs

• Pages/Cart.cshtml.cs

• Repository/PendingOrderRepository.cs

Pricing, Snapshots, and Analytics

PricingService fetches live per-card pricing from the YGO Pro Deck pricing endpoint. PricingDataCache avoids repeated retrieval, while the hosted background service runs nightly at midnight US Eastern to price owned/wishlisted cards, write dated value snapshots, and prune history. Dashboard and Stats consume persisted snapshots rather than requiring live pricing per request.

• Services/PricingService.cs

• Services/PricingDataCache.cs

• Services/PriceRefreshBackgroundService.cs

• Repository/ValueSnapshotRepository.cs

Runtime and Deployment

The system targets .NET 10 with EF Core 9, SQLite, Newtonsoft.Json, cookie authentication backed by BCrypt credentials, Bootstrap, and CDN Chart.js. Deployment is automated through GitHub Actions and a PowerShell/service-unit deployment path.

• CardCollector.csproj

• appsettings.json

• .github/workflows/deploy.yml

• scripts/card-collector.service