TaskHub.Shared

TaskHub.Shared.Refactoring - Technical Manual

The TaskHub.Shared.Refactoring module is a high-utility infrastructure tool that automates the tedious parts of .NET development: dependency injection registration and service metadata collection. It uses advanced reflection and assembly scanning to ensure that your application stays lean and consistent as it grows.

🏛 Deep Architecture

1. The Dependency Discovery Engine

The core of this module is the DependencyResolver. When the application starts, it performs a one-time scan of all loaded assemblies:

• Filter Logic: To maintain high startup performance, it ignores all “System”, “Microsoft”, “Newtonsoft”, and other common vendor assemblies. It focuses exclusively on your application’s domain and infrastructure projects.
• Marker Interface Matching: It looks for classes that implement specific marker interfaces:
  • IService: Registered as Scoped.
  • IRepository: Registered as Scoped.
  • IUnitOfWork: Registered as Scoped.
• Resolution Strategy:
  • Single Resolution (AddAppDependency<T>): It finds the exact implementation of interface T. If zero or >1 implementations are found, it throws a DependencyResolutionException, preventing ambiguous runtime behavior.
  • Multiple Resolution (AddAppDependencies<T>): It finds all classes implementing interface T and registers them as an IEnumerable<T>.

2. ServiceInfo Provider

The module provides a singleton ServiceInfo class that acts as a single source of truth for service metadata:

• Assembly Metadata: It reads the AssemblyInformationalVersionAttribute to determine the service version.
• Environment: It captures the machine name and .NET runtime version.
• Context: It is used by the Observability module to enrich logs and traces with the correct service name.

---

🛠 API Reference

DependencyBootstraper (Extension Methods)

| Method | Description | | :— | :— | | AddAppDependency<T>() | Scans for a single implementation of interface T and registers it. | | AddAppDependencies<T>() | Scans for all implementations of interface T and registers them. | | AddServiceInfo() | Registers the ServiceInfo singleton. |

[Unresolvable] Attribute

Decorate a class with this attribute to explicitly exclude it from the assembly scanning process. Useful for mock implementations or internal utility classes that shouldn’t be in the DI container.

---

🚀 Real-World Implementation Example

1. Automatic Repository Registration

// 1. Define Marker
public interface IOrderRepository : IRepository;

// 2. Implement
public class OrderRepository(MyDbContext db) : IOrderRepository { ... }

// 3. Register (in Program.cs or FullHostBuilder)
builder.Services.AddAppDependencies<IRepository>();

// 4. Inject anywhere
public class MyService(IOrderRepository repo) { ... }

2. Opting Out of Scanning

[Unresolvable]
public class TemporaryMockRepo : IOrderRepository { ... }

---

⚙️ Configuration Schema (appsettings.json)

While the logic is code-first, ServiceInfo can be influenced by the Service section:

"Service": {
  "Name": "TaskHub.ProjectService",
  "Environment": "Production"
}

---

👁 Telemetry & Diagnostics

Logs

During startup, the module logs:

• DependencyResolver: “Found {Count} implementations for {InterfaceName}”.
• ServiceInfo: “Service {Name} version {Version} started on .NET {Runtime}”.

---

✅ Best Practices & Anti-Patterns

🟢 Best Practices

• Use Markers: Always implement IService or IRepository for any new infrastructure or domain service to leverage auto-registration.
• One Implementation per Interface: For business services, stick to the AddAppDependency<T> pattern to catch accidental duplicate implementations early.

🔴 Anti-Patterns

• Circular Dependencies: Automated discovery doesn’t solve circular dependencies; ensure your service graph is a directed acyclic graph (DAG).
• Scanning Vendor Assemblies: Do not manually add vendor assemblies to the scanning filter, as this can drastically slow down startup and lead to accidental DI registrations.

This site is open source. Improve this page.