Skip to main content

Vital Core Extraction – Deep Dive Analysis

Executive Summary

This document provides a comprehensive technical analysis for extracting the Vital Core from the legacy EITWEP.Model project. The goal is to create a .NET Standard 2.1 portable layer that can be consumed by both the legacy .NET Framework 4.8 monolith and future .NET 10 Modern API.

[!CAUTION] Risk Level: HIGH – This is the most tightly coupled component in the architecture. Incorrect extraction will break 10+ dependent projects.


1. Current State Analysis

1.1 Project Metrics

MetricValueRisk
Total Files3,400+🔴 Massive scope
EntityClasses840🔴 Auto-generated, don't touch
EntityPartials369🟡 Custom logic, high coupling
EntityLists178🟡 Legacy query patterns
Business Files1,985🔴 Bloated, mixed concerns
Target Framework.NET 4.8🔴 Legacy
Entity Framework6.4.4🟢 Compatible with .NET Standard 2.1

1.2 Dependency Analysis

1.3 Legacy Coupling Points

A. System.Web Coupling (🔴 Critical)

300+ usages of HttpContext.Current found in EITWEP.Model.

[!NOTE] This is an instance of the Schizophrenic Architecture anti-pattern: the Data Layer should be HTTP-agnostic, but here it is tightly coupled to the Web context.

LocationCountImpact
WEPVDataContext_Partial.cs1Blocks SaveChanges() in non-web context
PaymentModeFactory.cs50+PayPal IPN handling
AspnetUserList.cs10+Cache access – see Session Locking
WepBOCacheAdapter.cs5+Cache invalidation
AsyncHelper.cs2Async context propagation

Why this is problematic: Microsoft explicitly discourages HttpContext.Current in modern .NET because it creates ambient state that prevents code reuse in non-web contexts (background jobs, CLI tools, unit tests).

[!TIP] Modern Alternative: Use Dependency Injection with IHttpContextAccessor injected where HTTP access is genuinely needed.

B. Legacy Interface Coupling

InterfaceImplementationsPurposeRelated Anti-Pattern
IWepActivityable18 entitiesActivity loggingLeaky Abstraction
IEITLogItemable71+ entitiesLog item creation-
ICommunicable50+ entitiesCommunication handlingGod Service (mixed responsibilities)
IEITNotifiableMultiplePush notifications-
IZohoSynchronizableMultipleZoho CRM sync-

Why interfaces are coupled: Many of these interfaces reference EITWEP.Model types in their signatures, creating circular dependencies. This violates the Dependency Inversion Principle.

C. System.Drawing / System.Windows.Forms

Found in EITWEP.Model.csproj:

  • System.Drawing – Used for image manipulation
  • System.Windows.Forms – Used for clipboard/dialogs (!)
  • System.Drawing.Design – Designer support

[!WARNING] This is a classic God Entity symptom: the data layer is doing image processing and UI operations, violating Single Responsibility.


2. Risk Assessment

2.1 Risk Matrix

Risk IDRisk DescriptionProbabilityImpactSeverityMitigation
R1Breaking 10+ dependent projectsHighCritical🔴Type Forwarding
R2SaveChanges() fails in non-web contextHighHigh🔴Inject IHttpContextAccessor
R3Interface circular dependenciesMediumHigh🟡Abstractions shim layer
R4LLBLGen regeneration overwrites changesLowHigh🟡Never touch generated files
R5Cache invalidation breaksMediumMedium🟡ICacheProvider abstraction – see Resource Leaks
R6Activity logging stops workingMediumMedium🟡Conditional HttpContext check

2.2 Critical Path Dependencies


3. Proposed Architecture

3.1 Why .NET Standard 2.1?

.NET Standard 2.1 is chosen as the target for several reasons:

  1. Maximum Compatibility – Compatible with .NET Core 3.0+, .NET 5+, and Mono (Xamarin)
  2. Entity Framework 6.4 Support – EF 6.4.4 targets .NET Standard 2.1
  3. Spans & Memory – Access to modern memory APIs for performance
  4. Future-Proof – All future .NET versions will support it

[!TIP] Reference: .NET Standard Documentation

3.2 Target Structure

3.3 Component Responsibilities

ComponentTargetContainsNotes
Wep.Core.Abstractions.NET Standard 2.1IWepActivityable, ICommunicable, IEITLogItemableZero dependencies
Wep.Core.Data.NET Standard 2.1EntityClasses, WEPV2DataContext configurationEF 6.4 only
Wep.Core.Domain.NET Standard 2.1Pure business logic, static helpersNo persistence
EITWEP.Model.NET 4.8 (Shim)Type Forwarding, Impure LogicExisting callers unchanged

3.4 Why Type Forwarding?

Type Forwarding (Microsoft Docs) is a .NET feature that allows moving types between assemblies without breaking existing callers.

Before:

WepNG_OMGT.dll → EITWEP.Model.dll (contains OrderOMGT)

After:

WepNG_OMGT.dll → EITWEP.Model.dll → [TypeForwardedTo] → Wep.Core.Data.dll (contains OrderOMGT)

The caller (WepNG_OMGT) doesn't need to change its code or references. The CLR resolves the type at runtime.


4. Implementation Phases

Phase A: Abstractions Shim (Week 1)

StepActionRiskRollback
A1Create new solution Wep.Core.slnNoneDelete folder
A2Create Wep.Core.Abstractions projectNoneDelete project
A3Copy IWepActivityable, IEITLogItemable, etc.🟡Revert git
A4Remove System.Web dependencies from interfaces🔴Keep in shim
A5Reference new project from EITWEP.Model🟡Remove ref

Phase B: Entity Extraction (Week 2-3)

StepActionRiskRollback
B1Create Wep.Core.Data project (.NET Standard 2.1)NoneDelete
B2Copy EntityClasses/*.cs (generated only)🔴Revert git
B3Configure WEPV2DataContext for new location🔴Keep original
B4Add Type Forwarding to EITWEP.Model🟡Remove
B5Update all project references🔴Revert all

Phase C: Logic Separation (Week 4+)

CategoryLocationExample
Pure LogicWep.Core.DomainFee calculation, date helpers, string utils
Impure LogicStays in EITWEP.ModelCache access, current user, activity logging

5. Prototype Validation Checklist

  • EITWEP.Model compiles with Type Forwarding
  • WepNG_OMGT references resolve correctly
  • OrderOMGT entity can be instantiated
  • SaveChanges() works with HTTP context
  • SaveChanges() works without HTTP context (headless)

6. Open Questions

  1. Build Order: How will CI/CD handle the new solution dependency?
  2. NuGet vs Project Reference: Should Wep.Core.* be NuGet packages or project references?
  3. LLBLGen Compatibility: Can LLBLGen Pro 4.2 generate to a .NET Standard 2.1 project?
  4. Test Coverage: Are there any existing unit tests for EITWEP.Model?

7. External References