Overview

Give application coordination an explicit execution boundary

DataArc.OrchestrationFramework brings together DataArc application orchestration, in-process execution observation, and Entity Framework Core integration through a single composition package.

Applications can coordinate explicit use-cases, execute application and persistence operations, observe outcomes, and retain normal .NET dependency injection and standard Entity Framework Core usage.

Supports .NET 6 through .NET 10.

Free to Use

Install the complete free DataArc application orchestration composition

DataArc.OrchestrationFramework is available free of charge.

Use the Framework in personal, commercial, educational, government, and enterprise .NET applications without purchasing a DataArc commercial license.

dotnet add package DataArc.OrchestrationFramework

Commercial SQL Server capabilities are available separately through DataArc.EntityFrameworkCore.SqlServer.

Framework Components

Focused packages composed into one application model

DataArc.Orchestrator

Provides explicit, strongly typed application orchestration through ordinary .NET classes with constructor-injected dependencies and defined input and output contracts.

DataArc.Observer

Provides in-process event dispatch, execution observation, and independently registered event handlers.

DataArc.EntityFrameworkCore

Provides free composable parallel execution and high-performance bulk operations on standard Entity Framework Core DbContext instances.

Composition, not ownership

Each package remains independently defined and continues to own its implementation responsibilities.

DataArc.OrchestrationFramework provides the composition layer that brings those capabilities together.

Register the Framework

Use normal .NET dependency injection

Orchestrators, observers, Entity Framework Core factories, and ordinary application dependencies are registered through the normal .NET dependency injection container.

services.AddDataArcCore();

services.AddDbContextFactory<DatabaseContextReadCommitted>(options =>
    options.UseSqlServer(connectionString));

services.AddDataArcOrchestrator(orchestrators =>
{
    orchestrators.Add<RepatriationOrchestrator>();
});

services.AddDataArcObserver(observer =>
{
    observer.Add<DataRepatriationSuccessObserver>();
    observer.Add<DataRepatriationFailureObserver>();
});

Complete Application Orchestration Flow

Coordinate execution from application input through observable outcome

A DataArc application can coordinate application execution, persistence, and execution observation through one explicit flow.

1. Receive strongly typed application input.
2. Execute an orchestrator.
3. Coordinate application services and persistence operations.
4. Return a strongly typed result.
5. Create an application event from the outcome.
6. Dispatch the event to independently registered observers.

Define Input and Output Contracts

Make the application boundary visible in code

Each orchestrator operates through explicit input and output contracts.

internal class OrchestratorInput : IOrchestratorInput
{
    public List<ForeignEntityExample> Data { get; set; } = new();
}

internal class OrchestratorOutput : IOrchestratorOutput
{
    public List<ForeignEntityExample> ForeignEntityExamples { get; set; } = new();
    public int AffectedRecords { get; set; }
    public bool Result { get; set; }
}

Coordinate the Application Use-Case

Keep application execution explicit

An orchestrator is an ordinary .NET class that coordinates a defined application use-case through normal constructor-injected dependencies.

In this example, an IDbContextFactory<TContext> creates a standard Entity Framework Core DbContext. The orchestrator uses the free DataArc parallel execution builder for the high-volume persistence work.

internal class RepatriationOrchestrator
    : Orchestrator<OrchestratorInput, OrchestratorOutput>
{
    private readonly IDbContextFactory<DatabaseContextReadCommitted>
        _databaseContextReadCommittedFactory;

    public RepatriationOrchestrator(
        IDbContextFactory<DatabaseContextReadCommitted>
            databaseContextReadCommittedFactory)
    {
        _databaseContextReadCommittedFactory =
            databaseContextReadCommittedFactory;
    }

    public override async Task<OrchestratorOutput> ExecuteAsync(
        OrchestratorInput input,
        OrchestratorOutput output)
    {
        var primaryEntities = input.Data
            .Select(x => x.PrimaryEntityExample)
            .ToList();

        var foreignEntities = input.Data.ToList();

        await using var dbContext =
            await _databaseContextReadCommittedFactory.CreateDbContextAsync();

        var affected = await dbContext
            .AsParallel()
            .AddBulk(primaryEntities, 100_000, "prim")
            .AddBulk(foreignEntities, 100_000, "foreign")
            .SaveChangesParallelAsync();

        output.ForeignEntityExamples = foreignEntities;
        output.AffectedRecords = affected;
        output.Result = true;

        return output;
    }
}

The orchestrator owns application coordination. Entity Framework Core continues to own its normal persistence behaviour. DataArc.Observer remains responsible for observation.

Execute the Application Use-Case

Invoke one explicit application boundary

Execute the orchestrator using its defined input and output contracts.

var result = await _orchestrator
    .OrchestrateAsync<
        RepatriationOrchestrator,
        OrchestratorOutput>(
        new OrchestratorInput
        {
            Data = data
        },
        new OrchestratorOutput());

The caller explicitly selects the orchestrator and receives its defined output directly. There are no hidden handler chains between the caller and the application use-case.

Observe the Application Outcome

Keep execution reactions outside the orchestrator

DataArc.Observer allows application outcomes to be observed independently from the application operation that produced them.

internal class DataRepatriationSuccessEvent : IObservableEvent
{
    public OrchestratorOutput Result { get; set; } = new();
}

internal class DataRepatriationFailureEvent : IObservableEvent
{
    public OrchestratorOutput Result { get; set; } = new();
}

Observers

internal class DataRepatriationSuccessObserver
    : IEventObserver<DataRepatriationSuccessEvent>
{
    public Task HandleAsync(
        DataRepatriationSuccessEvent evt)
    {
        Console.WriteLine(
            $"Success: {evt.Result.Result}");

        Console.WriteLine(
            $"Total Affected Records: {evt.Result.AffectedRecords:N0}");

        return Task.CompletedTask;
    }
}

internal class DataRepatriationFailureObserver
    : IEventObserver<DataRepatriationFailureEvent>
{
    public Task HandleAsync(
        DataRepatriationFailureEvent evt)
    {
        Console.WriteLine("Data repatriation failed.");

        return Task.CompletedTask;
    }
}

Dispatch the Result

Translate the application result into an observable event and dispatch it independently.

var events = new List<IObservableEvent>();

if (result.Result)
{
    events.Add(
        new DataRepatriationSuccessEvent
        {
            Result = result
        });
}
else
{
    events.Add(
        new DataRepatriationFailureEvent
        {
            Result = result
        });
}

await _observableEventHandler.DispatchAsync(events);

Application Flow

One explicit sequence with independently owned responsibilities

Application Input
      |
      v
Orchestrator
      |
      v
Application / Persistence Coordination
      |
      v
DataArc.EntityFrameworkCore
      |
      v
Orchestrator Output
      |
      v
Application Event
      |
      v
DataArc.Observer

An application workflow is the specific sequence of operations coordinated for a use-case.

DataArc provides application orchestration around that sequence without turning the application into a generic workflow engine.

Standard Entity Framework Core

Keep the persistence model you already use

DataArc.OrchestrationFramework does not require a replacement persistence model.

• DbContext
• IDbContextFactory<TContext>
• LINQ and Entity Framework Core queries
• Entity Framework Core transactions
• Tracked persistence operations
• Normal .NET dependency injection

Free DataArc parallel execution and bulk operations can be introduced only where composed or high-volume execution is required.

await using var dbContext =
    await dbContextFactory.CreateDbContextAsync();

await dbContext.AddBulkAsync(
    employees,
    100_000);

var affected = await dbContext
    .AsParallel()
    .Add(entity)
    .AddBulk(data, batchSize)
    .SaveChangesParallelAsync();

Commercial SQL Server Capabilities

Add transactional, multi-context, and relational database tooling separately

DataArc.EntityFrameworkCore.SqlServer is a separate commercial DataArc package. It is not required to use DataArc.OrchestrationFramework.

It adds SQL Server-specific capabilities including:

• Transaction-aware bulk inserts and deletes
• Participation in caller-owned Entity Framework Core transactions
• Parallel transactional execution
• Transactional execution pipelines
• Multi-context command coordination
• Multi-context query composition
• DataArc DDL Builder capabilities
• Relational model composition across multiple DbContext models

Commercial Registration

services.AddDataArcCore(options =>
    options.UseServerKey());

Parallel Transactional Execution

AsParallelTransaction() is provided by DataArc.EntityFrameworkCore.SqlServer. It uses the same compositional builder model as AsParallel() while executing through the commercial SQL Server transactional path.

var affected = await dbContext
    .AsParallelTransaction()
    .Add(entity)
    .AddBulk(data, batchSize)
    .CommitTransactionParallelAsync();

CommitTransactionParallelAsync() executes the queued operations through the DataArc transaction-coordinated parallel path.

Database and DDL Composition

Compose relational databases from independently defined DbContext models

The DataArc DDL Builder is provided by DataArc.EntityFrameworkCore.SqlServer.

var dbBuilder =
    _databaseBuilderFactory.CreateDatabaseBuilder();

var db = dbBuilder
    .IncludeDbContext<DatabaseContextReadCommitted>()
    .IncludeDbContext<DatabaseContextReadUncommitted>()
    .IncludeDbContext<DatabaseContextSerializable>()
    .IncludeDbContext<DatabaseContextRepeatableRead>()
    .IncludeDbContext<DatabaseContextSnapshot>()
    .Build(
        applyChanges: true,
        generateScripts: true);

db.ExecuteDrop();
db.ExecuteCreate();

A DbContext boundary does not have to become a relational boundary.

Multiple contexts can participate in one physical relational database with schemas, foreign keys, constraints, and database-enforced relational integrity. DataArc can also support multiple independent relational databases, each with its own connection string and relational model.

Application Orchestration

Coordinate application operations around a defined use-case

An orchestrator can coordinate:

• Application services
• Persistence operations
• Multiple DbContext instances
• Domain operations and policies
• External services
• Data transformations
• Notifications
• Execution observation

The coordination remains visible in application code.

Clean Architecture and Modular Monoliths

Coordinate boundaries without forcing distributed infrastructure

DataArc.OrchestrationFramework can sit at the application boundary of a modular system while individual modules retain their own services, policies, and Entity Framework Core contexts.

Application boundaries remain explicit without requiring those boundaries to become network boundaries or independent databases.

Integration Testing

Test the same application boundary used at runtime

Orchestrators are ordinary .NET classes with explicit dependencies and contracts. They can therefore be exercised through normal integration tests with the same registered services and persistence infrastructure used by the application.

Who It Is For

Applications where coordination deserves an explicit architectural boundary

DataArc.OrchestrationFramework is useful when an application operation spans multiple services or persistence concerns and the coordination should remain visible rather than being distributed across implicit handler pipelines.

Licensing

The Framework is free; commercial SQL Server tooling is separate

DataArc.OrchestrationFramework, DataArc.Orchestrator, DataArc.Observer, and DataArc.EntityFrameworkCore are available without purchasing a commercial DataArc license when used in accordance with their respective licenses.

Commercial licensing applies only when separately licensed functionality, including DataArc.EntityFrameworkCore.SqlServer, is used.

Installing or using the Framework does not grant rights to commercial DataArc functionality and does not require purchasing it.

Documentation

• Documentation: dataarc.dev
• Demo: DataArc.Orchestration.Framework.Demo public GitHub repository

Support

For support and commercial enquiries, contact support@dataarc.dev.