Skip to main content

📋 WepNG Platform: Architectural Audit (Strict Codebase Analysis)

Date: January 2026 Scope: WepNG_MVC Monolith Status: Baseline Assessment

1. Executive Summary​

This audit evaluates the WepNG_MVC platform based strictly on static code analysis of the current repository.

Verdict: The system is a Legacy Monolith (.NET 4.8) with high technical debt, but it is functionally stable. A "Big Bang Rewrite" to Microservices is not recommended due to the extreme tight coupling of the data layer (WEPV2ModelBuilder) and the heavy dependency on server-side UI logic (Kendo MVC).

Recommendation:

  1. Stabilize: Patch critical security holes (Legacy Auth, Cleartext Data).
  2. Modularize: Refactor "God Classes" to break internal dependencies.
  3. Strangle: Migrate only new isolated modules to modern stacks.

2. Quantitative Findings (The Hard Numbers)​

2.1 Volumetrics​

  • Lines of Code: ~850,000 LOC (Backend C#).
  • Complexity: Estimated ~16,000 Function Points.
  • Controllers: 765 (Heavy Logic Concentration).
  • Technology: ASP.NET MVC 5, Entity Framework 6, Kendo UI for MVC.

2.2 Critical Hotspots​

Static analysis identified three files that act as "Bottlenecks" for any refactoring effort. These files have high complexity and high churn (frequent modifications).

FileLines of CodeRisk Impact
WEPV2ModelBuilder.cs17,166Critical. This generated file maps the entire DB. It is a conflict magnet and prevents splitting the Data Context.
OrderTravelProductOMGT.cs7,108High. Core entity mixing Data, Validation, and Business Logic.
OrderOMGT.cs5,113High. Central Order entity.

3. Qualitative Findings (Architectural Patterns)​

3.1 The "Transaction Script" Pattern​

The Codebase does not follow a Domain-Driven Design (DDD) approach.

  • Observation: Logic is executed in procedural "ComponentServices" (e.g., ProfilOMGTComponentService).
  • Issue: These services mix concerns: they generate HTML string, execute EF Queries directly, and handle Authorization.
  • Consequence: Business logic cannot be easily extracted to a Microservice because it is tightly bound to the Web Context (HttpContext) and the UI (HTML generation).

3.2 The "Kendo MVC" Lock-in​

The frontend relies heavily on Telerik Kendo UI for MVC.

  • Mechanism: The DataSourceRequest object automatically translates UI Filters (Client) into SQL Queries (Server).
  • Lock-in: Moving to a "Headless" (React/Angular) frontend means losing this automation. You would need to manually rewrite ~400 filter endpoints.
  • Conclusion: A frontend rewrite purely for "modernization" has a negative ROI (Return on Investment).

4. Security & Risk (Immediate Actions)​

Our scan identified specific vulnerabilities that must be prioritized over architectural dreams:

  1. Legacy Authentication: AccountController still references Membership.ValidateUser (SQL Auth). This must be removed to enforce Azure AD Login.
  2. Sensitive Data Exposure: Medical details (diet, allergies) are stored as cleartext strings in Customer entities. Encryption is mandatory.
  3. CSRF Protection: Many Backoffice endpoints lack [ValidateAntiForgeryToken].

5. Strategic Roadmap​

Phase 1: Security & Stability​

  • Action: Encrypt Medical Data columns.
  • Action: Remove Membership auth fallback.
  • Action: Create a "Zero New Logic" policy for WEPV2ModelBuilder.

Phase 2: Decoupling (Modular Monolith)​

  • Action: Split the OMGT core domain from Reporting.
  • Technique: Introduce a Read-Only ReportingDbContext to stop the Reporting module from blocking the Transactional tables.

Phase 3: Modernization​

  • Target: Do NOT rewrite OrderMGT (The Core).
  • Target: Extract peripheral modules (e.g. Public API, standalone Tools) to .NET 8+.

Summary: The code tells us this is a heavy, coupled, but working system. Treat it with respect: Renovation, not Demolition.