<\/p>\n\n\n\n
Modern business applications rarely stay limited to a single export format. What usually begins as a simple \u201cExport to CSV\u201d button often evolves into a much broader requirement landscape:<\/p>\n\n\n\n
At first, these additions often seem harmless. A developer adds another This is exactly the kind of problem the GoF Strategy Pattern was designed to solve.<\/p>\n\n\n\n The Strategy Pattern allows us to encapsulate each export behavior independently and make export algorithms interchangeable without modifying the orchestration layer. Instead of building one enormous export service filled with conditional logic, we model each export format as its own isolated strategy.<\/p>\n\n\n\n The result is a system that is:<\/p>\n\n\n\n This article explores how to design a production-grade export architecture in C# using the Strategy Pattern, including deep code analysis, architectural considerations, dependency injection integration, testing approaches, performance concerns, and real-world enterprise implications.<\/p>\n\n\n\n Most export systems start very small.<\/p>\n\n\n\n Initially, there may only be a single requirement:<\/p>\n\n\n\n \u201cWe need CSV export.\u201d<\/p>\n<\/blockquote>\n\n\n\n A developer quickly implements something like this:<\/p>\n\n\n\n A few months later:<\/p>\n\n\n\n The method grows continuously:<\/p>\n\n\n\n This eventually creates several architectural problems.<\/p>\n\n\n\n The orchestration layer becomes tightly coupled to implementation details. The export service violates the Single Responsibility Principle because it now handles:<\/p>\n\n\n\n Testing also becomes increasingly painful because every export format is tangled together inside one growing class. A modification to PDF export can unintentionally affect CSV behavior. Over time, the export system becomes fragile and expensive to evolve.<\/p>\n\n\n\n This is precisely where the Strategy Pattern becomes valuable.<\/p>\n\n\n\n The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable.<\/p>\n\n\n\n In export systems, each export format becomes its own algorithm.<\/p>\n\n\n\n The architecture usually consists of three main components:<\/p>\n\n\n\n The strategy interface defines the common export contract:<\/p>\n\n\n\n Each concrete strategy encapsulates format-specific behavior:<\/p>\n\n\n\n The orchestration layer delegates execution to the selected strategy:<\/p>\n\n\n\n Even this simple structure already provides a major architectural improvement over large conditional blocks.<\/p>\n\n\n\n The orchestrator no longer cares about implementation details. CSV formatting logic stays inside the CSV strategy. PDF logic stays inside the PDF strategy. Each export behavior evolves independently.<\/p>\n\n\n\n However, while this baseline implementation demonstrates the core Strategy Pattern correctly, it still lacks many capabilities required in real production systems.<\/p>\n\n\n\n The educational example is structurally correct, but several important concerns are still missing.<\/p>\n\n\n\n The first major issue is synchronous execution. Real export operations are often IO-heavy and may involve:<\/p>\n\n\n\n A synchronous contract quickly becomes limiting in ASP.NET Core applications where scalability matters.<\/p>\n\n\n\n Another issue is the lack of cancellation support. Large exports may process hundreds of thousands of rows. Without The baseline implementation also returns only a raw Without these values, controllers must add extra format-specific logic elsewhere, partially defeating the purpose of Strategy.<\/p>\n\n\n\n There is also no built-in mechanism for identifying which strategy supports which export format. That often leads developers back to Finally, returning The Strategy Pattern itself is correct, but the contract must evolve to support real-world requirements.<\/p>\n\n\n\n A stronger export architecture usually introduces:<\/p>\n\n\n\n Instead of passing loose primitive values around the system, we define a strongly typed export format:<\/p>\n\n\n\n This eliminates magic strings and improves compile-time safety.<\/p>\n\n\n\n Next, we introduce a request object:<\/p>\n\n\n\n This design becomes extremely powerful as the system grows. Over time, export requests often require additional contextual information:<\/p>\n\n\n\n A request object allows the contract to evolve without constantly modifying method signatures.<\/p>\n\n\n\n We also introduce a richer export result model:<\/p>\n\n\n\n This encapsulates all HTTP-relevant metadata directly inside the export result.<\/p>\n\n\n\n The strategy contract then becomes:<\/p>\n\n\n\n This is significantly more production-ready.<\/p>\n\n\n\n Each strategy now self-identifies via Let us examine a more realistic CSV implementation.<\/p>\n\n\n\n Although this implementation appears straightforward, several important details deserve analysis.<\/p>\n\n\n\n The first is proper CSV escaping. CSV generation is often implemented incorrectly. Values containing commas, quotes, or line breaks must be escaped according to CSV rules. The strategy correctly wraps problematic values in quotes and duplicates internal quotation marks.<\/p>\n\n\n\n The use of Date handling is another subtle but important detail. Using the The strategy also checks Once strategies are implemented, we need a service responsible for resolving and executing the correct strategy.<\/p>\n\n\n\n The implementation looks like this:<\/p>\n\n\n\n This design provides several important architectural advantages.<\/p>\n\n\n\n Most importantly, the orchestrator no longer requires This aligns perfectly with the Open\/Closed Principle. The system remains open for extension while closed for modification.<\/p>\n\n\n\n The orchestrator itself now has a very narrow responsibility: strategy resolution and delegation. It does not contain formatting logic.<\/p>\n\n\n\n One of the reasons the Strategy Pattern works exceptionally well in modern .NET applications is the built-in dependency injection container.<\/p>\n\n\n\n Strategies can be registered like this:<\/p>\n\n\n\n ASP.NET Core automatically resolves:<\/p>\n\n\n\n This creates a plugin-like architecture with minimal infrastructure code.<\/p>\n\n\n\n Adding another format becomes almost trivial:<\/p>\n\n\n\n No central modification required.<\/p>\n\n\n\n The controller layer becomes extremely thin.<\/p>\n\n\n\n The controller does not know how CSV works. It does not know how PDF generation works. It only coordinates HTTP concerns and delegates export behavior to the application layer.<\/p>\n\n\n\n This separation is extremely valuable in layered architectures.<\/p>\n\n\n\n One of the major benefits of Strategy is testability.<\/p>\n\n\n\n Each export strategy can be tested independently.<\/p>\n\n\n\n CSV export tests typically verify:<\/p>\n\n\n\n The orchestrator itself also deserves dedicated tests. These tests focus on:<\/p>\n\n\n\n In larger systems, contract tests become especially valuable. Contract tests define shared expectations that every export strategy must satisfy:<\/p>\n\n\n\n This ensures consistency across teams and implementations.<\/p>\n\n\n\n Even with Strategy, several mistakes appear frequently in enterprise codebases.<\/p>\n\n\n\n One common issue is allowing strategies to fetch their own data.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n This couples rendering logic with data access logic. Strategies should focus on export behavior, not retrieval concerns.<\/p>\n\n\n\n Another common mistake is designing overly generic contracts such as:<\/p>\n\n\n\n This destroys type safety and usually leads to runtime casting problems.<\/p>\n\n\n\n Large exports also create memory issues when everything is buffered into a single A streaming-oriented contract may look like this:<\/p>\n\n\n\n This reduces memory pressure dramatically and enables true large-scale exports.<\/p>\n\n\n\n Another subtle but important issue involves localization. Export systems should never implicitly rely on server culture. Culture and timezone handling should be explicit parts of the request model.<\/p>\n\n\n\n Finally, silent fallback behavior should be avoided. Unknown formats should fail immediately instead of silently defaulting to CSV or another format.<\/p>\n\n\n\n The real value of Strategy becomes increasingly visible as systems grow.<\/p>\n\n\n\n Enterprise export systems often evolve toward requirements such as:<\/p>\n\n\n\n Without Strategy, these requirements usually create enormous monolithic export services.<\/p>\n\n\n\n With Strategy, complexity remains isolated.<\/p>\n\n\n\n Each export behavior evolves independently.<\/p>\n\n\n\n That isolation dramatically reduces regression risk and allows teams to extend the system safely over long periods of time.<\/p>\n\n\n\n The Export Strategy Pattern is far more than a \u201cclean code\u201d exercise.<\/p>\n\n\n\n It is a scalability mechanism for systems that must continuously evolve.<\/p>\n\n\n\n As export requirements grow, the Strategy Pattern provides architectural stability by isolating variability behind interchangeable behaviors. Instead of continuously modifying fragile conditional logic, developers extend the system incrementally through new strategies.<\/p>\n\n\n\n The result is an export architecture that remains maintainable even as complexity increases.<\/p>\n\n\n\n That is the real strength of the Strategy Pattern in modern C# applications:<\/p>\n\n\n\n controlled growth with minimized architectural friction.<\/p>\n","protected":false},"excerpt":{"rendered":" Modern business applications rarely stay limited to a single export format. What usually begins as a simple \u201cExport to CSV\u201d button often evolves into a much broader requirement landscape: At first, these additions often seem harmless. A developer adds another if statement, another switch branch, or another helper method. But over time, export logic tends […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,33,27,25],"tags":[],"class_list":["post-188","post","type-post","status-publish","format-standard","hentry","category-csharp","category-methods","category-programming-principles","category-software-engineering"],"_links":{"self":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/188","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=188"}],"version-history":[{"count":1,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/188\/revisions"}],"predecessor-version":[{"id":189,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/188\/revisions\/189"}],"wp:attachment":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=188"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=188"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=188"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}if<\/code> statement, another switch<\/code> branch, or another helper method. But over time, export logic tends to become one of the most fragile and difficult parts of many enterprise systems.<\/p>\n\n\n\n\n
\n\n\n\nThe Problem with Traditional Export Implementations<\/h1>\n\n\n\n
\n
public byte[] Export(string format, IEnumerable<OrderDto> orders)\n{\n if (format == \"csv\")\n {\n \/\/ CSV logic\n }\n\n return Array.Empty<byte>();\n}\n<\/code><\/pre>\n\n\n\n\n
public byte[] Export(string format, IEnumerable<OrderDto> orders)\n{\n if (format == \"csv\")\n {\n \/\/ CSV logic\n }\n else if (format == \"pdf\")\n {\n \/\/ PDF logic\n }\n else if (format == \"json\")\n {\n \/\/ JSON logic\n }\n else if (format == \"excel\")\n {\n \/\/ Excel logic\n }\n\n \/\/ more branches later...\n}\n<\/code><\/pre>\n\n\n\n\n
\n\n\n\nUnderstanding the Strategy Pattern<\/h1>\n\n\n\n
\n
public interface IExportStrategy\n{\n byte[] Export(IEnumerable<OrderDto> orders);\n}\n<\/code><\/pre>\n\n\n\npublic class CsvExportStrategy : IExportStrategy\n{\n public byte[] Export(IEnumerable<OrderDto> orders)\n {\n return Encoding.UTF8.GetBytes(\"Id;Total\\n1;99.90\");\n }\n}\n<\/code><\/pre>\n\n\n\npublic class PdfExportStrategy : IExportStrategy\n{\n public byte[] Export(IEnumerable<OrderDto> orders)\n {\n return new byte[] { };\n }\n}\n<\/code><\/pre>\n\n\n\npublic class ExportContext\n{\n private readonly IExportStrategy _strategy;\n\n public ExportContext(IExportStrategy strategy)\n {\n _strategy = strategy;\n }\n\n public byte[] Export(IEnumerable<OrderDto> orders)\n {\n return _strategy.Export(orders);\n }\n}\n<\/code><\/pre>\n\n\n\n
\n\n\n\nWhy the Baseline Design Is Not Enough for Production<\/h1>\n\n\n\n
\n
CancellationToken<\/code> support, export operations continue consuming CPU and memory even after a user aborts the request.<\/p>\n\n\n\nbyte[]<\/code>. In real systems, controllers typically require additional metadata:<\/p>\n\n\n\n\n
switch<\/code> statements in another layer.<\/p>\n\n\n\nbyte[]<\/code> for all exports creates memory pressure for large files because the entire export must be buffered in memory before being returned.<\/p>\n\n\n\n
\n\n\n\nDesigning a Production-Grade Export Contract<\/h1>\n\n\n\n
\n
public enum ExportFormat\n{\n Csv,\n Pdf,\n Json\n}\n<\/code><\/pre>\n\n\n\npublic sealed record ExportRequest(\n ExportFormat Format,\n IReadOnlyCollection<OrderDto> Orders,\n string? Culture = null);\n<\/code><\/pre>\n\n\n\n\n
public sealed record ExportResult(\n byte[] Content,\n string ContentType,\n string FileExtension,\n string FileName);\n<\/code><\/pre>\n\n\n\npublic interface IExportStrategy\n{\n ExportFormat Format { get; }\n\n Task<ExportResult> ExportAsync(\n ExportRequest request,\n CancellationToken ct = default);\n}\n<\/code><\/pre>\n\n\n\nFormat<\/code>. The contract supports asynchronous execution and cancellation. The result object becomes directly consumable by ASP.NET Core controllers.<\/p>\n\n\n\n
\n\n\n\nImplementing a Real CSV Export Strategy<\/h1>\n\n\n\n
public sealed class CsvExportStrategy : IExportStrategy\n{\n public ExportFormat Format => ExportFormat.Csv;\n\n public Task<ExportResult> ExportAsync(\n ExportRequest request,\n CancellationToken ct = default)\n {\n var sb = new StringBuilder();\n\n sb.AppendLine(\"Id,Customer,Total,CreatedUtc\");\n\n foreach (var order in request.Orders)\n {\n ct.ThrowIfCancellationRequested();\n\n sb.Append(order.Id).Append(',')\n .Append(Escape(order.CustomerName)).Append(',')\n .Append(order.Total.ToString(CultureInfo.InvariantCulture)).Append(',')\n .Append(order.CreatedUtc.ToString(\"O\"))\n .AppendLine();\n }\n\n var bytes = Encoding.UTF8.GetBytes(sb.ToString());\n\n return Task.FromResult(new ExportResult(\n bytes,\n \"text\/csv\",\n \".csv\",\n $\"orders-{DateTime.UtcNow:yyyyMMdd-HHmmss}.csv\"));\n }\n\n private static string Escape(string value)\n {\n if (string.IsNullOrEmpty(value))\n return \"\";\n\n var mustQuote =\n value.Contains(',')\n || value.Contains('\"')\n || value.Contains('\\n');\n\n if (!mustQuote)\n return value;\n\n return \"\\\"\" + value.Replace(\"\\\"\", \"\\\"\\\"\") + \"\\\"\";\n }\n}\n<\/code><\/pre>\n\n\n\nCultureInfo.InvariantCulture<\/code> is also critical. Numeric formatting must remain stable regardless of server locale. Without invariant formatting, decimal separators may differ between environments, producing inconsistent files.<\/p>\n\n\n\n\"O\"<\/code> format specifier generates ISO 8601 timestamps, which are machine-readable and locale-independent.<\/p>\n\n\n\nCancellationToken<\/code> inside the processing loop. This becomes extremely important for large exports because it allows long-running operations to terminate gracefully when the client disconnects.<\/p>\n\n\n\n
\n\n\n\nBuilding the Export Orchestrator<\/h1>\n\n\n\n
public interface IExportService\n{\n Task<ExportResult> ExportAsync(\n ExportRequest request,\n CancellationToken ct = default);\n}\n<\/code><\/pre>\n\n\n\npublic sealed class ExportService : IExportService\n{\n private readonly IReadOnlyDictionary<ExportFormat, IExportStrategy> _strategies;\n\n public ExportService(IEnumerable<IExportStrategy> strategies)\n {\n _strategies = strategies.ToDictionary(s => s.Format);\n }\n\n public Task<ExportResult> ExportAsync(\n ExportRequest request,\n CancellationToken ct = default)\n {\n if (!_strategies.TryGetValue(request.Format, out var strategy))\n {\n throw new NotSupportedException(\n $\"Export format '{request.Format}' is not supported.\");\n }\n\n return strategy.ExportAsync(request, ct);\n }\n}\n<\/code><\/pre>\n\n\n\nswitch<\/code> statements. Adding a new export format no longer modifies orchestration logic. Instead, developers simply create another strategy implementation and register it with dependency injection.<\/p>\n\n\n\n
\n\n\n\nDependency Injection Integration<\/h1>\n\n\n\n
services.AddScoped<IExportStrategy, CsvExportStrategy>();\nservices.AddScoped<IExportStrategy, PdfExportStrategy>();\nservices.AddScoped<IExportStrategy, JsonExportStrategy>();\n\nservices.AddScoped<IExportService, ExportService>();\n<\/code><\/pre>\n\n\n\nIEnumerable<IExportStrategy>\n<\/code><\/pre>\n\n\n\n\n
\n\n\n\nUsing the Export Service in ASP.NET Core<\/h1>\n\n\n\n
[ApiController]\n[Route(\"api\/exports\")]\npublic class ExportController : ControllerBase\n{\n private readonly IExportService _exportService;\n\n public ExportController(IExportService exportService)\n {\n _exportService = exportService;\n }\n\n [HttpPost(\"orders\")]\n public async Task<IActionResult> ExportOrders(\n [FromBody] ExportRequestDto dto,\n CancellationToken ct)\n {\n var request = new ExportRequest(\n dto.Format,\n dto.Orders);\n\n var result = await _exportService.ExportAsync(request, ct);\n\n return File(\n result.Content,\n result.ContentType,\n result.FileName);\n }\n}\n<\/code><\/pre>\n\n\n\n
\n\n\n\nTesting the Strategy Pattern Properly<\/h1>\n\n\n\n
\n
\n
\n
\n\n\n\nCommon Architectural Pitfalls<\/h1>\n\n\n\n
public class CsvExportStrategy\n{\n private readonly DbContext _db;\n}\n<\/code><\/pre>\n\n\n\nTask<byte[]> ExportAsync(object data);\n<\/code><\/pre>\n\n\n\nbyte[]<\/code>. In high-volume systems, streaming becomes preferable.<\/p>\n\n\n\npublic interface IStreamingExportStrategy\n{\n ExportFormat Format { get; }\n\n Task ExportAsync(\n Stream output,\n ExportRequest request,\n CancellationToken ct = default);\n}\n<\/code><\/pre>\n\n\n\n
\n\n\n\nWhy the Strategy Pattern Scales So Well<\/h1>\n\n\n\n
\n
\n\n\n\nFinal Thoughts<\/h1>\n\n\n\n