DEV Community: max-arshinov

Computation Expressions: an F# feature I wish I had but that will never be implemented in C#

max-arshinov — Mon, 09 Oct 2023 16:36:39 +0000

Seasoned developers like myself sometimes invariably stumble upon charming paradigms in one language that evokes longing when coding in the other. One spellbinding feature from the F# toolkit is F# Computation Expressions. While we can dream, it’s a feature unlikely to find a home in C#.

Introducing a Use Case

To scrutinize what’s at stake, let's dissect an example inspired by my previous article, which highlights two irksome aspects of C#:

public async Task<IActionResult> ChangeEmail(int userId, string newEmail)
{
    User existingUser = await _userRepository.GetByEmailAsync(newEmail);
    if (existingUser != null && existingUser.Id != userId)
    {
        return BadRequest();
    }

    User user = await _userRepository.GetByIdAsync(userId);
    newEmail = CanonicalizeEmail(newEmail);
    user.ChangeEmail(newEmail);
    await _userRepository.SaveAsync(user);
    await _notifications.SendAsync(user);
    return Ok();
}

The DRY Challenge

The code snippet below tends to be repetitive. DRY (Don't Repeat Yourself) becomes a hurdle when navigating through the asynchronous verification mechanism in C#.

User existingUser = await _userRepository.GetByEmailAsync(newEmail);
if (existingUser != null && existingUser.Id != userId)
{
    return BadRequest();
}

The “async/await” Predicament

The Task keyword dictates an unavoidable cascade of "async all the way" down your call stack.

Though neither of these issues critically undermines code maintainability, they can ruffle the feathers of developers striving for elegant code, especially those involved in code reviews.

Introducing F# to the Stage

F# provides a splendidly terse and comprehensible alternative. Don't worry if you're not familiar with the syntax as I only want to compare the readability of the C# and the F# versions:

let changeEmail =
    validateRequest
    >> canonicalizeEmail
    >> updateDbFromRequest
    >> sendEmail
    >> returnMessage

As you've probably guessed, validateRequest, canonicalizeEmail, and the whole changeEmailWorkflow are just functions.
The composition operator >> takes two functions and returns a function.

Visual aids borrowed from Scott Wlaschin's Railway Oriented Programming illustrate this point wonderfully.

Even those who are unfamiliar with the syntax can read and understand it. In fact, you can even show this code to non-technical people and most likely they will be able to read and understand the snippet. When reformulated in a less idiomatic F# style, an extra layer of verbosity and complexity becomes apparent:

let changeEmailWithLet (request: ChangeEmailCommand) =
    let validated = validateRequest request 
    let canonicalized = canonicalizeEmail validated
    let updated = updateDbFromRequest canonicalized
    let sent = sendEmail updated
    returnMessage sent

Despite this, it still maintains arguably better readability than its C# counterpart. Regardless, this transformation is essential for understanding the main concept of this article.

Unraveling Computation Expressions

F#'s Computation expressions furnish developers with a syntax that allows computations to be sequenced and combined in a delightful manner. But let's shift from definition to practice, with a result computation as an example:

Result

The Result<'T,'TError> type lets you write error-tolerant code that can be composed.

// The definition of Result in FSharp.Core
type Result<'T,'TError> =
    | Ok of ResultValue:'T
    | Error of ErrorValue:'TError

This function employs the Result<'T,'TError> type to yield an Ok or Error return.

let divide x y = 
    if y = 0.0 then Error "Cannot divide by zero"
    else Ok (x / y)

The caller has to match the returning value and check if it's an Ok or an Error case. This kind of checking might be tedious and messy when we need to chain several division operations like on the code snippet below:

let compute a b c d =
    match divide a b with
    | Error e -> Error e
    | Ok division ->
        match divide c d with
        | Error e -> Error e
        | Ok anotherDivision -> Ok (division + anotherDivision)

When chain-linked through various operations, the simplicity and efficacy of computation expressions shine. Instead of nesting match/with expressions, we can wrap divisions in the result {} context so we can use let! and return:

let result = ResultBuilder()

let compute a b c d =
    result {
        let! division = divide a b
        let! anotherDivision = divide c d
        return division + anotherDivision
    }

The code within the result {} context is a computation expression. The programmer is free to define the semantics of the context. In our case we want to continue execution on Ok and skip execution on Error.

type ResultBuilder() =
    member _.Bind(x, f) =
        match x with
        | Ok v -> f v
        | Error e -> Error e
    member _.Return(x) = Ok x

The Bind function enables the let! keyword. It "unwraps" the Result<'T, string> value by chaining the following results of the computation expression.

x is the result of divide a b
f is the remaining part of the computation that depends on unwrapped value of x:

let! anotherDivision = divide c d
return division + anotherDivision

The Return function enables the return keyword so the whole computation still returns Result<'T, string>. This is why Result<'T, string> is defined as a way to write error-tolerant code that can be composed.

Validation

Once written, the ResultBuilder can be applied to any workflow that works with any Result<'T,'Terror> type. Let's apply it to the original "Update Email" use-case:

type SimpleResult<'T> = Result<'T, string> // It can be any error type. String is for simpicity reasons only.

let changeEmail request =
    result {
        let! validated = validateRequest request // unwraps Result
        let canonicalized = canonicalizeEmail validated
        let! updated = updateDbFromRequest canonicalized // unwraps Result
        let! sent = sendEmail updated // unwraps Result
        return sent // wraps the result
    } |> returnMessage // SimpleResult<ChangeEmailCommand> -> IActionResult

You might notice that let canonicalized = canonicalizeEmail validated is the only line that uses a regular version of let instead of let!. That's because it returns ChangeEmailCommand rather than Result<ChangeEmailCommand, 'TError>. There is no need to unwrap the returning value. It wasn't wrapped because the function can't fail.

Compare it to the previous version. I only slightly updated the last line with the forward pipe |> operator to make it consistent with the computation-expressions-based version of the code:

let changeEmailWithLet request =
    let validated = validateRequest request
    let canonicalized = canonicalizeEmail validated
    let updated = updateDbFromRequest canonicalized
    let sent = sendEmail updated
    sent |> returnMessage

It's not very different, right? The beauty of computation expressions is that they are a generic concept. They are not limited to Result<'T, 'TError>. For instance, Task<'T> has built-in support of computation expressions.

Blending Asynchronicity and Validation

Moreover, it's possible to build a computation expression that supports both error handling and asynchronicity:

type TaskResult<'T> = Task<SimpleResult<'T>>

type TaskResultBuilder<'T>() =
    member _.Bind(x: SimpleResult<'T>, f: 'T -> TaskResult<'U>) : TaskResult<'U> =
        // ...
    member _.Bind(x: TaskResult<'T>, f: 'T -> TaskResult<'U>) : TaskResult<'U> =
        // ...

    member _.Return(x: 'T) : TaskResult<'T> = 
        // ...

    member _.Return(x: SimpleResult<'T>) : TaskResult<'T> = 
        // ...

You can find the implementation details in Mark Seemann's Task asynchronous programming as an IO surrogate.

The code inside remains the same despite all functions are now asynchronous. We are now using the enhanced taskResult computation expression that supports the Task<Resut<'T, 'TError> type.

let changeEmail request =
    taskResult {
        let! validated = validateRequest request // unwraps TaskResult
        let canonicalized = canonicalizeEmail validated
        let! updated = updateDbFromRequest canonicalized // unwraps TaskResult
        let! sent = sendEmail updated // unwraps Result
        return sent // wraps TaskResult
    } |> returnMessage // TaskResult<ChangeEmailCommand> -> Task<IActionResult>

Note that despite the let! sent = sendEmail updated // ChangeEmailCommand -> SimpleResult<ChangeEmailCommand> type definition lacks asynchronicity we can still use let! thanks to the overloaded implementation of Bind from the TaskResultBuilder<'T> definition above.

Operator Overloading

Last but not least. The code example above is still verbose. All these parameters we had to add to make let! work ruin the beauty of the original example. The good news is that F# supports operator overloading! There is even a well-known convention for monadic compositions. It's called "Kleisli composition" or just "fish operator": >=>. Let's define the Kleisli composition operator and two additional operators that might be handy:

>=> : composes functions that are both asynchronous and can fail.
>>> : composes asynchronous functions that can fail and simple functions that can't fail.
>?> : composes asynchronous functions that can fail and synchronous functions that can fail.

let changeEmailKleisli =
    validateRequest // 'T -> TaskResult<'T>
    >>> canonicalizeEmail // canonicalizeEmail is synchronous and always successful
    >=> updateDbFromRequest // updateDbFromRequest is asynchronous and can fail
    >?> sendEmail // sendEmail is synchronous and can fail
    >> returnMessage // return message just translates the Result type to IActionResult

Let's compare it to the original F# example:

let changeEmail =
    validateRequest
    >> canonicalizeEmail
    >> updateDbFromRequest
    >> sendEmail
    >> returnMessage

There is indeed some minor difference: the original example only uses >> while the latter version leverages more advanced composition types: >>, >=>, >>>, >?>. These operators might be confusing at first. However, in the long run, I like that the operators are different. As a code reviewer, I might be interested in what kind of composition. Different operators make it clear that the final workflow consists of functions with different signatures.

Limitations of the Parameterless Version

Alas, despite being review-friendly, the last variant is not without drawbacks. I can name two major ones.

Debugging experience

Whichever composition >>, >=>, >>>, >?> is used, there is no way to set a breakpoint on a junction side. Thus, to debug the composed function one needs to add breakpoints inside of the bodies of the composed function. This is the price one has to pay for getting rid of let keywords and parameters. Arguably, this is a major tradeoff between two maintainability aspects.

Operators are Stateless

Until now, all our builders had parameterless constructors. However, they don't have to. Should we need to add logging support, only one modification of Bind is required. Unlike Scala, there is no straightforward way to inject a dependency into an operator in F# ... Maybe it's a good thing, though.

type TaskResultBuilder<'T>(logger: ILogger<'T>) =
    member _.Bind(x: TaskResult<'T>, f: 'T -> TaskResult<'U>) : TaskResult<'U> =
    // add logging here...
    // it will trigger on every let!

//...

let taskResult = TaskResultBuilder(logger)

Why This Feature Will Never Be Implemented in `C#`

C# follows a completely different design approach: async/await, yield, LINQ, all these quality-of-life features. While F# gives developers powerful but sometimes too generic and not always easy-to-grasp abstractions, C# uses specific and somewhat opinionated (in a good way) tools that do just one thing but do it great. The difference in these two approaches to language design might be as significant as the OOP/Functional-first natures of C# and F# correspondingly.

While there are ways to implement weird things by abusing async/await keywords or the SelectMany method, these are at most amusing exercises rather than production-ready solutions.

Conclusion

The elegance and conciseness of F# offer undeniable allure, particularly when contrasted against specific use cases in C#. While F# bestows a straightforward approach to managing asynchronicity and validation, C# developers can only peer into this functional world with a hint of envy.

Domain Services in DDD: Navigating Through Validation and Dependency Management

max-arshinov — Tue, 03 Oct 2023 18:59:50 +0000

Models abstract and simplify reality to make it understandable and computable. By doing so, certain nuances and details are inevitably omitted. Domain models are no exception. The last time we ended up with the following design of the UserProfile class:

public class UserContact
{
    public EmailAddress Email { get; protected set; } // protected for EF

    public Phone Phone { get; protected set; } // protected for EF

    protected UserContact(){} // protected for EF

    public static UserContact Create(EmailAddress email) => 
        new() { Email = email }; 

    public static UserContact Create(Phone phone) =>
        new() { Phone = phone };

    public static UserContact Create(
        EmailAddress email, Phone phone) => 
        new() { Email = email, Phone = phone };
}

What if we needed to change the email of the user?

public class UserContact
{
    // ...
    public void ChangeEmail(EmailAddress newEmail)
    {
        Email = newEmail;
    }
}

Validation typically takes two forms:

Contextless: Ensures the self-consistency of an object, for example EmailAddress constructor guards implemented one way or another.
Contextual: Verifies an object concerning external factors, like ensuring user email uniqueness across a system.

// UserController
public Task<IActionResult> ChangeEmail(int userId, EmailAddress newEmail)
{
    // Contextual validation
    User existingUser = await _userRepository.GetByEmailAsync(newEmail);
    if (existingUser != null && existingUser.Id != userId)
    {
        return BadRequest();
    }

    User user = await _userRepository.GetByIdAsync(userId);

    user.ChangeEmail(newEmail);
    await _userRepository.SaveAsync(user);

    return Ok();
}

DDD Trilemma: A Crucial Tradeoff in Design

In his thought-provoking analysis, Vladimir Khorikov introduces the concept of the DDD Trilemma, highlighting a pivotal choice developers must make:

Preserve domain model completeness and purity at a potential cost to performance.
Maintain performance and model completeness while sacrificing purity.
Uphold performance and model purity but compromise on completeness.

Making Decisions Based on Queries

Coincidentally, Scott Wlaschin in his book “Domain Modeling Made Functional” (which I strongly recommend even for those who are not familiar with F#) recommends keeping the pure functions intact, but placing them between impure I/O functions if pushing I/O towards application boundaries is not an option because of performance reasons.

Simplifying Decisions: Two Robust Rules

In C#, I found it useful to domain Domain Services should the need arise:

Maintain Purity: use constructors, required keyword accompanied by Value Objects for the “pure” (IO-less) parts of your model.
Domain logic fragmentation is a lesser evil: use domain services for I/O operations, preserving the absence of IO in your entity classes. Introduce a domain service anytime you need the async/await. Don't create async methods in your entity classes. Don't use synchronous IO because it obscures the impurity.

These rules make it so it's easy to choose between an entity method and a service. However, there is one notable exception of the infamous Aggregate pattern, which I'd like to discuss next time.

F# Discriminated Unions vs. C# Class Hierarchies: A Design Perspective

max-arshinov — Mon, 25 Sep 2023 20:21:46 +0000

Let's expand on the previous User class example. Let our user be a customer of an online store.

Once a customer finalizes an order, any post-dispatch modifications risk integrity breaches. It's essential to ensure the order data's privacy and integrity.

public class User
{
    // ...

    public IEnumerable<Order> Orders { get; init; }
}

public partial class Order
{
    public bool IsValidated { get; init; }
    public decimal? Price { get; init; }
    public IEnumerable<OrderItem> OrderItems { get; init; }
}

For instance, consider the typical procedures related to an order: verifying warehouse inventory, processing shipments, and handling cancellations.

Is it necessary to confirm inventory before processing payment?

That hinges on specific business rules.

public partial class Order
{
    // Validated
    public bool IsValidated { get; init; }
    public decimal? Price { get; init; }
}

Can we ship an order prior to receiving payment?

Some retailers permit payment upon delivery, especially for local shipments.

public partial class Order
{
    // Shipped
    public bool IsShipped { get; init; }
    public string? TrackingUrl { get; init; }
}

And what if a delivered order needs to be canceled?

Perhaps our system requires a more nuanced status than merely "canceled." A "dispute" status might be more apt, prompting further inquiries: Was the item damaged en route? Was there an error at the warehouse? Or did the customer mistakenly receive what they actually ordered?

public partial class Order
{
    // Cancelled
    public bool IsCancelled { get; init; }
    public string? CancellationReason { get; init; }
}

Problem statement

public class User
{
    // ...

    public IEnumerable<Order> Orders { get; init; }
}

public class Order
{
    // Validated
    public bool IsValidated { get; init; }
    public decimal? Price { get; init; }
    public IEnumerable<OrderItem> OrderItems { get; init; }

    // Shipped
    public bool IsShipped { get; init; }
    public string? TrackingUrl { get; init; }

    // Cancelled
    public bool IsCancelled { get; init; }
    public string? CancellationReason { get; init; }
}

The intricacies related to specific order states are only meaningful within their respective contexts. In C#, the class design might not always explicitly indicate the relationship between an order's status and its content. This singular class attempts to capture diverse order states, leading to potential ambiguities. How can we better encapsulate these states and the associated business logic?

Discriminated Unions

F# offers discriminated unions (DU) to address such challenges:

type ValidatedOrder = {
    Price: decimal
}

type ShippedOrder = {
    TrackingUrl: string
}

type CancelledOrder = {
    CancellationReason: string
}

type Order =
    | New
    | Validated of ValidatedOrder
    | Shipped of ShippedOrder
    | Cancelled of CancelledOrder

DUs are akin to enhanced enums in F#, allowing encapsulation of distinct states and their associated data. They're typically used with pattern matching for clarity.

let matchOrder order =
    match order with
    | Shipped s -> $"Tracking URL: {s.TrackingUrl}"
    | Cancelled c -> $"Reason: {c.CancellationReason}"

"Closed" Type Hierarchies

For those rooted in C#, the discriminated unions proposal has been around for quite some time. Apparently, it's not going to
make it in C#12 mainly because of several important discussion threads:

Proposal: Add completeness checking to pattern matching draft specification roslyn #188
Proposal: "Closed" type hierarchies #485
Discussion: Unions/closed hierarchies/ADTs, which one does C# 7.1+ need & what would the spec look like? #75

The "discriminated unions" and the "closed type hierarchies" are both viable language design alternatives and potent implementation options for the Order class. In this specific case, we even don't need the hierarchy to be "closed" Let's check the difference between the DU and the hierarchy approaches:

public abstract class OrderBase
{
    public IEnumerable<OrderItem> OrderItems { get; init; }    
}

public class ValidatedOrder : OrderBase
{
    public decimal? Price { get; init; }
}

public class ShippedOrder : OrderBase
{
    public string? TrackingUrl { get; init; }
}

public class CancelledOrder : OrderBase
{
    public string? CancellationReason { get; init; }
}

Coincidentally, that's how EF core handles hierarchies by default.

Control Flow

The biggest difference between these two implementation options is how the control flow is organized. Discriminated unions use pattern matching while closed type hierarchies rely on good, old polymorphism.

Some people will claim the former option is more "functional" while the latter is more "object-oriented". Practically speaking, C# switch statements/expressions are, unlike F# match, not exhaustive. One of the main advantages of "closed" hierarchies is that they give us a list of all derived types at the compile time.

Concluding Thoughts

Whether using Discriminated Unions in F# or exploring Closed Type Hierarchies in C#, the goal remains: clear, maintainable, and robust code that accurately represents business logic and reduces room for errors. Leveraging the best of both functional and object-oriented paradigms can lead to superior code quality.

Robust Design through Value Objects in C#

max-arshinov — Mon, 18 Sep 2023 16:24:36 +0000

In our previous discussion, we delved into the creation of the UserContact class, honoring idiomatic C# patterns with the utilization of DataAnnotations attributes and the TryParse method. Despite its functionality, the reliance on DataAnnotations attributes has been criticized as a design smell, a perspective that holds merit. How can we ensure the robustness of our UserContact class while avoiding potential design pitfalls?

Enriching C# with F# Insights

An ideal solution seems to be embracing the F# approach of "narrowing" existing types to create self-validating, robust value types:

type EmailAddress = private EmailAddress of string

let createEmailAddress (s:string) =
    if System.Text.RegularExpressions.Regex.IsMatch(s,@"^\S+@\S+\.\S+$")
        then Some (EmailAddress s)
        else None

let emailAddress = createEmailAddress "foo@bar.com"

This F# snippet gives us a glimpse of a design where types guarantee the correctness of the values they hold, reducing runtime errors and simplifying the code.

Bridging the Gap in C#

While C# currently lacks direct support for this kind of functionality, there's a glimmer of hope with an active proposal under discussion that aims to bring this feature to the language. This potential addition promises a future where C# can natively offer similar robust type narrowing.

As we anticipate advancements in C#, we can still forge ahead with crafting resilient applications by utilizing the "ValueOf" package as a provisional solution. Below, we create a validated EmailAddress class leveraging the package:

public class EmailAddress : ValueOf<string, EmailAddress> 
{ 
    protected override bool TryValidate()
    {
        var index = Value.IndexOf('@');

        var isValid =
            index > 0 &&
            index != Value.Length - 1 &&
            index == Value.LastIndexOf('@');

        return isValid;
    }

    protected override void Validate()
    {
        if (!TryValidate())
        {
            throw new ValidationException($"{Value} is not a valid email address");
        }
    }
}

// ...

EmailAddress emailAddress = EmailAddress.From("foo@bar.com");

Not only does this approach centralize validation logic, but it also paves the way for cleaner and more maintainable code.

Revamping the `UserContact` Class

Let's refactor the UserContact class from the previous article with ValueOf:

public class UserContact
{
    public EmailAddress Email { get; protected set; } // protected for EF

    public Phone Phone { get; protected set; } // protected for EF

    protected UserContact(){} // protected for EF

    public static UserContact Create(EmailAddress email) => 
        new() { Email = email }; 

    public static UserContact Create(Phone phone) =>
        new() { Phone = phone };

    public static UserContact Create(
        EmailAddress email, Phone phone) => 
        new() { Email = email, Phone = phone };
}

In this renovated version, we introduce dedicated types for Email and Phone, ensuring type safety and facilitating various creation methods for different scenarios, be it with an email, a phone number, or both. Also, thanks to the protected access modifier, fields, and the empty constructor are accessible for Entity Framework but not for developers without using reflection.

Revamping the `User` Class

Let's go further and a SignUp type representing a command from the frontend:

public class User
{
   public int Id { get; protected set; } // protected for EF

   public Contact Contact { get; protected set; } // protected for EF

   public Profile? Profile { get; protected set; } // protected for EF

   protected User() {} // protected for EF

   public User (SignUp command)
   {
       Contact = command.Contact;
       Profile = command.Profile;
   }
}

We can even add a specialized constructor per user creation use case:

public class User
{
   //...

   public User (SignUpByInvite command): this(command)
   {
       Invitee = command.Invitee;
   }    
}

Now it has become clear that a user can register independently (SignUp) or register through a friend's invitation (SignUpByInvite). The invitation mechanism might lead someone reading the code to think that there is a referral program in the system. This change has another unexpected side effect. Imagine that there are two different error messages in the logs:

Something went wrong during user registration
Something went wrong when Alice tried to register through Bob's invitation

The second message is much more informative. It specifies Alice and Bob, and the specific registration process, rather than an abstract registration error. Thus, maintaining the product will be somewhat easier for new developers, who are not familiar with all the requirements.

Conclusion

As we've traversed the nuances of enhancing type safety in our UserContact class, we see how leaning towards a type-centric design, inspired by F# practices and facilitated by the "ValueOf" package, crafts a framework that is both robust and resistant to typical design smells.

Yet, it's pivotal to note a significant consideration when working with the "ValueOf" package in a .NET environment, particularly in context with the ASP.NET Core model binding. "ValueOf" is not supported by default. You have to implement a custom model binder if you want to use these kinds of value objects in your DTOs.

As we wrap up, it would be remiss not to encourage you to experiment with creating a Phone type, akin to the EmailAddress type.

Eradicating the Primitive Obsession

max-arshinov — Thu, 14 Sep 2023 17:17:35 +0000

Before we delve deeper into the intricacies of domain-driven design, I highly recommend taking a moment to familiarize yourself with the essential terms and concepts that will be discussed throughout this article.

Recalling our previous discussion where we initiated the design of a user class and identified issues that were preventing us from implementing the Rich Domain Model, let’s take it a step further by rectifying the anemic implementation that we previously derived. Here is what the anemic implementation might look like:

public class User
{
   public int Id { get; init; }

   public string? FirstName { get; set; } // Profile
   public string? LastName { get; set; } // Profile
   public string? MiddleName { get; set; } // Profile

   public string? Phone { get; set; } // Contact
   public string? Email { get; set; } // Contact  
}

This is a perfect example of a common anti-pattern, referred to as "primitive obsession," where developers lean heavily on primitive data types instead of crafting dedicated classes or structures to house domain ideas. This is often considered as a significant code smell.

One can claim that this User hasn't decided if he/she is a unicorn or a goat :) There is no invariant here because the class is no more than a bag of properties.

To resolve this, we introduce a technique called “Make illegal states unrepresentable” to help eradicate this obsession and reinforce the robustness of our design through the integration of new UserProfile and UserContact classes.

public class UserProfile
{
   // now required
   public required string FirstName { get; init; }

   // now required
   public required  string LastName { get; init; }

   public string? MiddleName { get; init; }
}


public class UserContact
{
   public string? Phone { get; init; }
   public string? Email { get; init; }
}

Thanks to C#9's init keyword coupled with C#11 required modifier, enforcing the setting of the first and last names is possible, even without a constructor. Here is how I can initialize a profile:

var profile = new UserProfile
{
   FirstName = "Max",
   LastName = "Arshinov"
};

Adding Constructor

Despite these improvements, a loophole exists - it's still possible to initialize the profile with empty strings. To fix this, we introduce a constructor that validates these fields to prevent such initialization:

public class UserProfile
{
   public UserProfile(string firstName, string lastName,
      string? middleName = null)
   {
       FirstName = firstName;
       LastName = lastName;
       MiddleName = middleName;
       this.EnsureInvariant();
   }


   [Required]
   public string FirstName { get; protected set; }

   [Required]
   public string LastName { get; protected set; }

   public string? MiddleName { get; protected set; }
}

Now, our constructor ensures that first and last names are provided, making our class more robust against erroneous inputs.

Ensure Invariant

To further beef up our class, we introduce a method, EnsureInvariant, which helps in validating the object state after its initialization. Here is the implementation of this method.

public static class FunctionalExtensions
{
   private static ConcurrentDictionary<Type, IValidator> 
       _validators = new();

   public static void EnsureInvariant(this object obj,
       bool validateAllProperties = true)
   {
       Validator.ValidateObject(
           obj,
           new ValidationContext(obj),
           validateAllProperties);
   }
}

Or slightly different if you prefer FluentValidaton.

public static void EnsureInvariant<TEntity, TValidator>(
   this TEntity obj)
   where TValidator: AbstractValidator<TEntity>, new()
{
   var ctx = new ValidationContext<TEntity>(obj,
       new PropertyChain(),
       ValidatorOptions
         .Global
         .ValidatorSelectors
         .DefaultValidatorSelectorFactory());

   var result = _validators.GetOrAdd(typeof(TEntity), 
      _ => new TValidator()).Validate(ctx);

   if(!result.IsValid)
   {
       throw new ValidationException(
        "Validation failed: " + string.Join(",
        result.Errors.Select(e => e.ErrorMessage)));
   }
}


//…
this.EnsureInvariant<UserProfile, UserProfileInvariantValidator>();

The above skeleton can be fleshed out with actual validation logic to ensure the object's state's correctness.

User Contact

Turning our attention to the contact information, we encounter a similar predicament. We aim to define parameters that are not merely optional but follow certain validation rules. Here is an evolved UserContact class adhering to this principle:

public class UserContact
{
   const string PhonePattern = @"\+?\d";

   [EmailAddress]
   public string? Email { get; protected set; }

   [RegularExpression(PhonePattern)]
   public string? Phone { get; protected set; }

   public UserContact(string? email, string? phone)
   {
       Email = email;
       Phone = phone;
       this.EnsureInvariant();
   }
}

I could use such a constructor, but in C# there is no way to indicate that one of the parameters is mandatory. The method signature will indicate that both parameters are optional. Therefore, let's make the constructor private and instead provide two public methods with more descriptive names. In C#, the prefix Try is usually used for operations that can fail but do not throw exceptions. We can implement the constructor in the following way.

public class UserContact
{
   const string PhonePattern = @"\+?\d";

   [EmailAddress]
   public string? Email { get; protected set; }

   [RegularExpression(PhonePattern)]
   public string? Phone { get; protected set; }

   private Contact(string? email, string? phone)
   {
       Email = email;
       Phone = phone;
   }

   public static bool TryParsePhone(string phone,
      out Contact? c)
   {
       if (PhoneRegex.IsMatch(phone))
       {
           c = new Contact(null, phone);
           return true;
       }

       c = null;
       return false;
   }
}

Wrapping up

We now have a User type that embodies two subtypes: UserContact and UserProfile. With these changes, our User class has transitioned from being anemic to a more rich and robust representation, promoting easier maintenance and fewer errors during development.

public class User
{
   public required int Id { get; init; }

   public required UserContact Contact { get; init; }

   public UserProfile? Profile { get; init; }
}

That’s all for today. The next time, we’ll evolve this design even more towards the Rich Domain Model.

Always Valid — A Myth or a Tangible Reality?

max-arshinov — Mon, 11 Sep 2023 21:11:47 +0000

In the vast landscape of object-oriented programming (OOP), the division into "rich" and "anemic" domain models has crafted distinct pathways for developers. Unlike in functional programming (FP), where this bifurcation is less pertinent due to the paradigm’s distinctive approach to handling data and behavior, OOP offers a rich ground for this exploration. This piece aims to journey through the intricacies of OOP, with occasional references to insights from the FP domain.

Rich Model

Envisioned by Martin Fowler and Erik Evans, the rich model emphasizes a holistic approach where:

Data structure and behavior reside harmoniously in one class, fostering cohesion.
The code embodies the business domain's structure, promoting class names that resonate with the business logic rather than adhering strictly to design patterns or frameworks.
Maintaining object invariants is central, facilitating non-contradictory states and lending a robust foundation to the architecture.

Anemic Model

Conversely, the anemic model, often perceived as an anti-pattern by critics, delineates data and behavior, resulting in:

Separate entities and services to house data structures and their operations respectively.
A focus on patterns and frameworks rather than mirroring the business domain through code, potentially making the deciphering of business rules through code analysis a demanding task.
A relaxed approach to invariants, with a portion of practitioners negating the necessity to do so. Despite its criticisms, proponents argue for its alignment with SOLID principles, seeing it as a future-forward approach.

Despite Fowler and Evans labeling the anemic model an anti-pattern, suggesting that development teams failed to model the domain in an OOP style correctly, many programmers are convinced that it is precisely what is needed — some even see it as the future. Moreover, it strictly adheres to SOLID principles.

Unraveling the Origins of the Split

Tracing the genesis of this split is complex. A pivotal role might have been played by:

Overdominance of ORM: The prevalent use of ORM, underscored by the notable download statistics of Entity Framework, hints at ORM’s overwhelming presence in web applications.
ORM conventions are not always rich-model-friendly, so ORM users tend to implement anemic models.
Simplicity of Implementation: The anemic model often becomes a go-to due to its straightforward implementation, despite the rich model holding theoretical allure.

Always Valid — A Myth or a Tangible Reality?

In domain modeling, "always valid" refers to a principle or strategy where the objects or entities within the domain are always in a valid state. It is a means of maintaining the integrity of a system by ensuring that changes to an entity always result in a valid state for that entity.

Invariants are conditions that are always true for a particular entity. Under the "always valid" strategy, invariants are rigorously maintained, meaning an entity cannot exist in an invalid state with respect to its defined invariants.

Maintaining object invariants is essential when implementing the domain the "rich way". The contentious debate surrounding the viability of maintaining “always valid” states veers towards a skeptical lens. Despite its conceptual appeal promoting error detection at the compilation stage, it meets practical hurdles.

To ensure the correctness of the state of any object in a mutable environment, we will have to equip any setter with a protective structure, for example, like this:

public class User 
{
    private string _name;
    public string Name
    {
        get { return _name; }
        set
        {
           if (string.IsNullOrEmpty(value))
           {
               throw new Exception("Name is required");
           }
           _name = value;
        }
    }
}

This approach not only heavily clutters and noisifies the code but also really does not get along with SOLID, because such classes have two reasons for changes: data storage and validation. To not violate the principle of single responsibility, we could declare a separate validator interface, implement it, and transfer the validation logic to the corresponding implementation.

public interface IValidator<T>
{
   ValidationResult Validate(T obj);
}

Moreover, sometimes it may simply be impossible to ensure the correct state of objects. Business people have realized a long time ago that the likelihood of making a purchase in an online store decreases depending on the number of required forms to fill out. Ideally, there should only be one huge "buy" button and some way to contact the user. The call center can fill out other "necessary" fields after receiving payment.

On the other hand, the more the store knows about the customer, the better it can set up marketing campaigns to show more relevant ads, which are more likely to make them go to the store's website to buy something again and again.

Thus, in some cases, there should be a minimum of required fields, and in others — a maximum. This means that in different contexts, the rules for the "mandatory" fields of a class can be different, and the class instance cannot always be in the "right" state, because "correctness" depends on the current context.

The Problem of Universals

It is amazing that long before the invention of computers, similar questions were first raised in known human history by Plato and Aristotle. I will not delve too deeply into ontology. Hopefully, the ancient Greek philosophers forgive me for a quite free interpretation of their ideas...

Imagine a unicorn. Not a specific one, but an abstract concept. Now imagine an object that belongs to the “unicorns” class. Here I interpret the terms object and class broadly: not in the sense of OOP terminology, but as a category that includes all possible unicorns and one representative of this category. Do you think the toy on the picture below is a unicorn?

Ok, what about this one?

This is a one-horned goat named Lucky.

Lucky, is a character from the cartoon "Despicable Me 3," throughout which a little girl was looking for a live unicorn because the unicorn on the first picture is her favorite toy... and overall, well..., she found it. What do the ancient Greek philosophers and modern cartoons have to do with contextual validation? Surprisingly, the link is quite straightforward.

Contextual Validation and Invariant

Qualities necessary for an object to belong to a certain class: a unicorn is still a horse with one horn, not a sheep with two horns, one of which broke off.

Depending on the context, there are other types of validation that work in addition to the invariant. In the sales context, it is enough for the user to have contact details, and in the delivery context, the first and last name becomes mandatory, and possibly other necessary fields.

At first glance, such a division allows you to keep the model in a consistent state. In theory, yes, but in practice, there are pesky corner cases.

Stay tuned...

Debugging Docker Compose Solutions in JetBrains Rider: A Deep Dive

max-arshinov — Fri, 08 Sep 2023 13:20:27 +0000

Introduction

If you've ever used JetBrains Rider's built-in feature for debugging Docker and Docker Compose solutions, you may have found it works like a charm — or maybe not. I encountered issues with this feature where the debugger just wouldn't kick off. Unable to discern a pattern, I decided to investigate how Rider handles Docker Compose debugging under the hood. In this article, we'll walk through the setup, explore the commands Rider uses, dissect the generated Docker Compose file, and learn how to troubleshoot common issues.

Setting Up a Simple Web App Project

To understand how Rider's debugging works, I started by creating a basic C# web application. Below is the Dockerfile for the application.

# Dockerfile
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443


FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["Service1/Service1.csproj", "Service1/"]
RUN dotnet restore "Service1/Service1.csproj"
COPY . .
WORKDIR "/src/Service1"
RUN dotnet build "Service1.csproj" -c Release -o /app/build


FROM build AS publish
RUN dotnet publish "Service1.csproj" -c Release -o /app/publish /p:UseAppHost=false


FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "Service1.dll"]

The Docker Compose Configuration

I also created a docker-compose.yml file and an override file, docker-compose.override.yml, to manage the services.

# docker-compose.yml
version: '3.8'

services: 
 service1:
   image: service1
   build:
     context: .
     dockerfile: ./Service1/Dockerfile


 service2:
   image: service2
   build:
     context: .
     dockerfile: ./Service2/Dockerfile

# docker-compose.override.yml
version: '3.8'

services:
 service1:
   ports:
     - 8081:80


 service2:
   ports:
     - 8082:80

Initiating Debugging in Rider

After configuring the Docker Compose setup in Rider, I clicked the "Debug" icon to initiate the debugging process.

Understanding the Command Rider Uses

Rider's approach diverges from what one might expect, which is the docker-compose up -f command. If you take a look at the Service/Console window, you'll see the command Rider actually uses:

/usr/local/bin/docker compose -f /path/to/docker-compose.yml -f /path/to/docker-compose.override.yml -f /path/to/docker-compose.generated.override.yml -p project up -d

Note: I am using a Mac, so the file paths might differ on a Windows system.

Analyzing the Generated Docker Compose File

Rider generates an additional Docker Compose override file that provides crucial settings for debugging. Here's a simplified snippet:

# This is a generated file. Not intended for manual editing.
version: "3.8"
services:
 service1:
   build:
     context: "/Users/marshinov/Work/tools/DockerDebug"
     dockerfile: "./Service1/Dockerfile"
     target: "base"
   command: []
   entrypoint:
   - "/riderDebugger/linux-arm64/dotnet/dotnet"
   - "/riderDebugger/JetBrains.Debugger.Worker.exe"
   - "--mode=server"
   - "--frontend-port=57100"
   - "--backend-port=57300"
   environment:
     ASPNETCORE_ENVIRONMENT: "Development"
     DOTNET_USE_POLLING_FILE_WATCHER: "true"
     NUGET_PACKAGES: "/Users/marshinov/.nuget/packages"
     NUGET_FALLBACK_PACKAGES: "/Users/marshinov/.nuget/packages"
     RIDER_DEBUGGER_LOG_DIR: "/riderLogs"
     RESHARPER_LOG_CONF: "/riderLogsConf/backend-log.xml"
   image: "service1:dev"
   ports:
   - "127.0.0.1:57002:57100"
   - "127.0.0.1:57202:57300"
   volumes:
   - "/Users/marshinov/.nuget/packages:/root/.nuget/fallbackpackages"
   - "/Users/marshinov/Work/tools/DockerDebug/Service1:/app:rw"
   - "/Users/marshinov/Work/tools/DockerDebug:/src:rw"
   - "/Users/marshinov/.local/share/JetBrains/RiderRemoteDebugger/2023.2.1/LinuxArm64:/riderDebugger"
   - "/Users/marshinov/Library/Application Support/JetBrains/Toolbox/apps/Rider/ch-0/232.9559.61/Rider.app/Contents/bin:/riderLogsConf"
   - "/Users/marshinov/Library/Logs/JetBrains/Rider2023.2/DebuggerWorker/JetBrains.Debugger.Worker.2023_9_06_12_27_11:/riderLogs:rw"
   working_dir: "/app"
 service2:
   build:
     context: "/Users/marshinov/Work/tools/DockerDebug"
     dockerfile: "./Service2/Dockerfile"
     target: "base"
   command: []
   entrypoint:
   - "/riderDebugger/linux-arm64/dotnet/dotnet"
   - "/riderDebugger/JetBrains.Debugger.Worker.exe"
   - "--mode=server"
   - "--frontend-port=57100"
   - "--backend-port=57300"
   environment:
     ASPNETCORE_ENVIRONMENT: "Development"
     DOTNET_USE_POLLING_FILE_WATCHER: "true"
     NUGET_PACKAGES: "/Users/marshinov/.nuget/packages"
     NUGET_FALLBACK_PACKAGES: "/Users/marshinov/.nuget/packages"
     RIDER_DEBUGGER_LOG_DIR: "/riderLogs"
     RESHARPER_LOG_CONF: "/riderLogsConf/backend-log.xml"
   image: "service2:dev"
   ports:
   - "127.0.0.1:57003:57100"
   - "127.0.0.1:57203:57300"
   volumes:
   - "/Users/marshinov/.nuget/packages:/root/.nuget/fallbackpackages"
   - "/Users/marshinov/Work/tools/DockerDebug/Service2:/app:rw"
   - "/Users/marshinov/Work/tools/DockerDebug:/src:rw"
   - "/Users/marshinov/.local/share/JetBrains/RiderRemoteDebugger/2023.2.1/LinuxArm64:/riderDebugger"
   - "/Users/marshinov/Library/Application Support/JetBrains/Toolbox/apps/Rider/ch-0/232.9559.61/Rider.app/Contents/bin:/riderLogsConf"
   - "/Users/marshinov/Library/Logs/JetBrains/Rider2023.2/DebuggerWorker/JetBrains.Debugger.Worker.2023_9_06_12_27_11:/riderLogs:rw"
   working_dir: "/app"

This generated file performs several tasks:

Attaches the Rider Remote debugger
Overrides the original entry point to use the Rider Remote Debugger
Ignores DLLs in the original image and uses source code mounted via volumes
Opens additional ports for debugging

These changes are transformative, so much so that Rider essentially creates a completely different runtime environment, optimized for debugging.

Troubleshooting: The Issue I Faced

In my case, Rider ignored environment variables defined in my .env file, which are usually considered by the docker-compose up -d command. The COMPOSE_PROJECT_NAME variable, in particular, led to confusion when toggling between standard Docker commands and Rider-based debugging. To resolve this, I had to explicitly specify the project name in Rider's Docker Compose settings.

Conclusion

After digging deep into how JetBrains Rider handles Docker Compose debugging, I've found a reliable workaround for the issues I was facing. Rider performs several substantial changes to your Docker Compose configurations to enable debugging, so understanding these can be key to troubleshooting effectively. I hope this deep dive saves you some time and helps you debug your applications more efficiently. Happy coding!

P.S. Visual Studio does a similar thing.

Implementing Simon Brown's Minimal Approach to Software Architecture Documentation

max-arshinov — Wed, 06 Sep 2023 16:21:40 +0000

"The question of 'how much documentation should we write?' is often asked, especially in the age of remote work and business continuity planning."

If you've read Simon Brown's (@simonbrown) take on a minimal approach to software architecture documentation, you may have been intrigued by the concept but perhaps left wondering about its implementation.

This repo fills that gap by presenting a concrete implementation template of Simon Brown's approach, which consists of:

Check this out if you've been looking for a robust starter kit for your marvellous adventure in the land of Architecture as Code.

Happy documenting! 📚

Integration Testing: Devs and QAs

max-arshinov — Mon, 13 Mar 2023 15:33:06 +0000

In the previous articles, we breached the border between integration and unit tests, which introduces a tricky question: how to effectively organize collaboration between devs and QAs. Here is my take on that:

[DEV] Create Controller Method
[DEV] Create <CONTROLLER_NAME>TestsBase<T> class
[DEV] Create Waf<CONTROLLER_NAME>Tests: ControllerTestsBase<T>
[DEV] Implement the controller method
[DEV] Implement a test in <CONTROLLER_NAME>TestsBase<T>
[DEV] Submit a merge request
[DEV] Merge the request and move Jira issue to "ready for testing"
[CI/CD] Automatically run WAF tests
[QA] Create Http<CONTROLLER_NAME>Tests: <CONTROLLER_NAME>TestsBase<T>
[QA] Add missing configs to make the test work in both classes
[QA] Submit a merge request
[DEV or/and QA] Merge the request
[CI/CD] Automatically deploy to the test env
[CI/CD] Automatically run http tests
[QA] Do manual testing if needed
[QA] Resolve Jira issue

As you can see on the BPMN diagram, developers are responsible for the implementation and web-application-factory-based (WAF) tests, while QAs are responsible for testing: both automated using real HTTP calls to real environments. For me, this approach makes more sense than any other one, and that’s why:

The flow encourages test-driven development. WAF tests are great substitutes for traditional unit tests: they are fast, isolated from external dependencies, and still provide code coverage statistics.
The flow encourages collaboration, teamwork, and shared code ownership between developers and QAs. This is very in the spirit of DevOps.
The flow favors the black-box approach over the white-box approach. White-box tests tend to be more fragile because they don’t respect encapsulation.
All team members do things that they can do best: developers have more experience with coding than QAs. It’s not arrogance or something, they just do coding on a regular basis. QAs in turn, are more concerned about test datasets and scenarios. Most likely, the QA team will be happy to get some help with coding so they can focus on quality.

A note about test data

Preparing and cleaning up the test data might be tedious, error-prone, and time-consuming. Property-based testing technique introduces another approach that focuses on fixing system properties, rather than input/output combinations. Sometimes this approach is worth considering.

Consider the following code:

[Fact]
public async Task LoadMany_GetById_CanFetchAllProductsFromGetAll()
{
  var res = await ControllerClient
    .SendAsync(c => c.Get())
    .LoadMany(
      p => ControllerClient.SendAsync(c => c.Get(p.Id)),
      p => p.Id);

   res.Should().AllSatisfy(x =>
   {
     x.Value.Details.Should().NotBeNull();
     x.Value.Details?.Id.Should().Be(x.Key);
   });
}

It checks that every id returned from GET /products can be provided as a parameter to GET /products/{id} and that /products/{id} returns the expected product data. No data setup is needed, albeit two endpoints are checked with great coverage %.

Web Application Factory VS Real HTTP Calls - Take Two

max-arshinov — Sat, 11 Mar 2023 15:51:45 +0000

I’d say that Web-Application-Factory-based integration tests are really close to the bottom border of the "integration" section of the test pyramid.

You might want to have a good level of isolation to be able to run them as a part of the CI/CD pipeline and .NET provides many options such as:

Mocking services entirely;
Using EF Core In-Memory Database Provider or SQLite-InMemory;
Using Docker for tests.

By favouring isolation, however, we sacrifice the accuracy of testing. Issues related to the transport layer, third-party services, or DB can’t be found when using mocks because all of these are isolated from tests. On the other hand, the higher we climb the test pyramid the more expensive and fragile the tests become. Luckily, it’s possible to reuse a lot of code that we already have to build integration tests that would adjoin the upper side of the “integration tests” section of the pyramid.

Let’s say we have a Post controller method implemented somewhat like this:



public async Task<PostResult> Post(InputParams input) {
    var valueFromDb = await GetValueFromDbAsync(input);
    var valueThirdPartyService = await
        GetValueFromThirdPartyServiceAsync(valueFromDb);

    return new PostResult(
        valueFromDb, valueThirdPartyService);
}

Both GetValueFromDbAsync and GetValueFromThirdPartyServiceAsync are isolated by injecting mock services to the web application factory. To make sure that the controller method works not only with mocks but with the real DB and third-party service we are going to implement a test that would call the real API endpoint deployed to the test environment.

The code of the web-application-factory-based test works just fine



public class MyControllerTest:
    ControllerTestBase<MyController> 
{
    [Theory]
    [ClassData(typeof(SophisticatedDataProvider))]
    public async Task ReturnsSucces(
        InputParams input, ExpectedOutput expectedOutput)
    {
        // Arrange
        var client = _factory.CreateControllerClient();

        // Act
        var outputData = await client.SendAsync(
            (MyController c) => c.Post(input));

        // Assert
        ComplexAssertions(expectedOutput, outputData);
    }
}

except for this time we need the real HttpClient to do real calls to the real environment unlike the HttpClient implementation provided by the Web Application Factory.

Applying Template Method Pattern

Let’s refactor the original test by applying Template Method pattern.



public abstract class HttpClientTestBase<T>
    where T: IHttpClientFactory
{
    protected readonly T HttpClientFactory;

    public HttpClientTestsBase(T http)
    {
        HttpClientFactory = http;
    }

    protected HttpClient CreateHttpClient(string name = "")
        => HttpClientFactory.CreateClient(name);
}

public class ControllerTestBase<
    TController,
    THttpClientFactory
>:
    HttpClientTestsBase<THttpClientFactory> 
    where THttpClientFactory : IHttpClientFactory
{
    public ControllerTestBase(THttpClientFactory http) :
        base(http) {}

    public ControllerClient<TController>
        CreateControllerClient(string name = "") => 
            new(CreateHttpClient(name));
}

public abstract class MyControllerTestBase:
    ControllerTestBase<MyController, TFactory> 
    IClassFixture<TFactory> 
    where TFactory : class, IHttpClientFactory
{
    protected MyControllerTestBase(THttpClientFactory http) :
        base(http) {}

    [Theory]
    [ClassData(typeof(SophisticatedDataProvider))]
    public async Task ReturnsSucces(
        InputParams input, ExpectedOutput expectedOutput)
    {
        // Arrange
        var client = CreateControllerClient();

        // Act
        var outputData = await client.SendAsync(
            (MyController c) => c.Post(input));

        // Assert
        ComplexAssertions(expectedOutput, outputData);
    }

Complete source code of HttpClientTestBase and ControllerTestBase is available on GitHub.

Albeit CreateControllerClient method is not abstract, it only delegates all work to HttpClientFactory, which in turn will be provided in the derived class. Thus, this is a variant of the “template method” implementation that uses composition instead of inheritance.



public class MyControllerWafTest:
    MyControllerTestBase<MoqHttpClientFactory>
{
    MyControllerWafTest(MoqHttpClientFactory factory):
        base(factory){}
}

public class MyControllerHttpTest:
    MyControllerTestBase<HttpClientFactory>
{
    MyControllerWafTest(HttpClientFactory factory):
        base(factory){}
}

Test frameworks such as xUnit or NUnit will skip the base class since it’s abstract but will execute tests from both derived classes. As a result, we shared the test code between web-application-factory-based and real-http-client-based tests.

Configuring Mocks

For the web-application-factory-based test we need mocks set up. Microsoft recommends using ConfigureTestServices to do so. That’s a nice and convenient way to override service registrations, but in order to keep as much code as possible shared between web-application-factory-based and real-http-client-based tests we'll move mock registration from the test method to the class constructor.



MyControllerWafTest:
    MyControllerTestBase<MoqHttpClientFactory>
{
    MyControllerWafTest(MoqHttpClientFactory factory):
        base(factory)
    {
        _factory.ConfigureMocks(nameof(ReturnsSucces), m => {
            m
               .Mock<ISomeRepository>
               .Setup(x => x.GetAll())
               .Returns(new [] {/*...*/});

        });
    }
}

[Theory]
[ClassData(typeof(SophisticatedDataProvider))]
public async Task ReturnsSucces(
    InputParams input, ExpectedOutput expectedOutput)
{
    // Arrange
    var client =
        CreateControllerClient(nameof(ReturnsSucces));

    // Act
    var outputData = await client.SendAsync(
        (MyController c) => c.Post(input));

    // Assert
    ComplexAssertions(expectedOutput, outputData);
 }

The code above benefits from the IHttpClientFactory definition. Mocks for each named instance of HttpClient are configured independently. We only needed to update the client creation code to get the named HttpClient instance with mocks configured for this method:
var client = CreateControllerClient(nameof(ReturnsSucces));

What if I don’t want to share some tests

Just don’t do it. Put tests that you want to run in both modes into the base class and add feel free to add additional tests to derived test classes when needed. The complete code can be found on GitHub. You can also use the nuget package for you projects.

A note on modular architecture

This type of tests is better aligned with modular architecture.

Expression Trees + Web Application Factory = ❤️

max-arshinov — Fri, 10 Mar 2023 17:19:08 +0000

Web Application Factory dramatically improves the developer experience. However, it can be even better. First of all, let’s check the example from the Microsoft website.

public class BasicTests 
    : IClassFixture<WebApplicationFactory<Program>>
{
    private readonly WebApplicationFactory<Program> _factory;

    public BasicTests(WebApplicationFactory<Program> factory)
    {
        _factory = factory;
    }

    [Fact]
    public async Task ReturnsSucces(string url)
    {
        // Arrange
        var client = _factory.CreateClient();
        var url = "about";


        // Act
        var response = await client.GetAsync(url);

        // Assert
        response.EnsureSuccessStatusCode();

        Assert.Equal("text/html; charset=utf-8", 
            response.Content.Headers.ContentType.ToString());
    }
}

That’s cool. I can run high-level integration tests before deploying the code to an environment. This option reduces the efforts of detecting and fixing defects because integration tests can be run during the implementation phase, just before submitting a merge request.

Unfortunately, this example is far from being realistic. What we really want to test might look like this:

    [Theory]
    [ClassData(typeof(SophisticatedDataProvider))]
    public async Task ReturnsSucces(
        InputParams input, ExpectedOutput expectedOutput)
    {
        // Arrange
        var client = _factory.CreateClient();
        var url = "enpoint-with-a-lot-of-code-branches";


        // Act
        var content =
            CreatePostContentFromInputParams(input);
        var response = await client.PostAsync(url, content);

        // Assert
        response.EnsureSuccessStatusCode();

        var outputData = response
            .Content
            .ReadAsJsonAsync<OutputParams>();
        ComplexAssertions(expectedOutput, outputData);
    }
}

Urls and input parameters are subject to change. Despite we have access to all the required .NET code through the assembly reference, which we need anyway to make the web application factory work, we have to do model binding and routing on our one in the test code. What if we could do something like:

public class MyControllerTest:
    ControllerTestBase<MyController> 
{
    [Theory]
    [ClassData(typeof(SophisticatedDataProvider))]
    public async Task ReturnsSucces(
        InputParams input, ExpectedOutput expectedOutput)
    {
        // Arrange
        var client = _factory.CreateControllerClient();


        // Act
        var outputData = await client.SendAsync(
            (MyController c) => c.Post(input));

        // Assert
        response.EnsureSuccessStatusCode(); 
        ComplexAssertions(expectedOutput, outputData);
    }
}

If When routes or input/output parameters change developers would know about these issues first. This would reduce the efforts of detecting and fixing defects again by introducing compile-time safety for the test code. Luckily, the example above can perfectly work with help of Expression Trees. Moq uses exactly the same technique to configure mocks.

 var mock = new Mock<ILoveThisLibrary>();
 Mock
  .Setup(library => 
    library.DownloadExists("2.0.0.0")) // Check lambda type
 .Returns(true); // it's expression!

You can find the complete source code of Controller Client on GitHub in case you are interested. Otherwise just install AspNetCore.Testing.Expressions via nuget and become an alpha tester.

A brief history of async/await

max-arshinov — Sat, 22 Oct 2022 21:30:28 +0000

The async/await pattern is a syntactic feature of many programming languages that allows an asynchronous, non-blocking function to be structured similarly to an ordinary synchronous function. It is semantically related to the concept of a coroutine and is often implemented using similar techniques.

Perhaps, the first mainstream language that adopted this feature was C#. During the next decade, the feature spread across many other languages:

2012 — C# 5
2015 — Python 3.5, TypeScript 1.7
2017 — ECMAScript 2017
2018 — Kotlin 1.3
2019 — Rust
2020 — C++ 20
2021 — Swift

That being said, in 2022 one can state async/await, implemented one way or another, is an industry standard. Despite that C# was the first mainstream language that popularised the async/await keywords, it wasn’t the language that invented the concept. F# added asynchronous workflows with await points in version 2.0 in 2007 (5 years before C#).

It’s interesting that with version 6 release in 2021 (14 years later) the recommended async pattern in F# was changed from async to task. At first glance, these two pieces of code look almost identical:

// async
let readFilesTask (path1, path2) =
   async {
        let! bytes1 = File.ReadAllBytesAsync(path1) |> Async.AwaitTask
        let! bytes2 = File.ReadAllBytesAsync(path2) |> Async.AwaitTask
        return Array.append bytes1 bytes2
   } |> Async.StartAsTask

// task
let readFilesTask (path1, path2) =
   task {
        let! bytes1 = File.ReadAllBytesAsync(path1)
        let! bytes2 = File.ReadAllBytesAsync(path2)
        return Array.append bytes1 bytes2
   }

Ironically, the new recommended way is less functional (in the sense of functional programming) than the original one. Consider the following code:

let a = async {
   printfn "async"
}
let seq = seq {a; a}

printfn "Begin"
seq |> Seq.iter Async.RunSynchronously
printfn "End"

It will print:

Begin
async
async
End

If we removed seq |> Seq.iter Async.RunSynchronously then the output would be just:

Begin
End

In other words, Async is lazy by default. It will not start unless the code is awaited. Async will not cache the result as well. If we changed this code in favour of using tasks:

let t = task {
   printfn "task"
}

let seq = seq {t; t}

printfn "Begin"
seq |> Seq.iter  (Async.AwaitTask >> Async.RunSynchronously)
printfn "End"

We would see:

task
Begin
End

Not only tasks start as soon as they are created. Tasks' results are also cached. The await or let! keywords would check Task.IsCompleted property. When true, tasks are executed synchronously because the result is already cached in the Task.Result property.

Why does it matter? I highly recommend reading Async as surrogate IO by Mark Seemann and its comments. In a nutshell, I believe that async/await got a lot of inspiration from the Haskel IO monad which was released in Haskell 98. I'm not claiming that F# Async was a direct translation of Haskell's IO, but there are similarities. In this sense, Async has a much more in common with its monadic predecessor than Task.

In the end, F#, the language that brought academic concepts to the object-oriented world, adopted the implementation from C#. The task computation expression works on top of TPL library, so it has better interoperability with Task-based .NET async pattern. Practically speaking, F# fixed discrepancies between the platform and the language syntax. Every other language from the list above also tends to represent the async/await syntax by futures/promises or similar data structures. Referential transparency is not guaranteed in any of these implementations though.

P.S. Haskell lead developer Simon Marlow created the async package in 2012, the same year when async/await was introduced in C#.
P.P.S. It’s possible to abuse async/await syntax to build monad comprehensions in C#.

DEV Community: max-arshinov

Computation Expressions: an F# feature I wish I had but that will never be implemented in C#

Introducing a Use Case

The DRY Challenge

The “async/await” Predicament

Introducing F# to the Stage

Unraveling Computation Expressions

Result

Validation

Blending Asynchronicity and Validation

Operator Overloading

Limitations of the Parameterless Version

Debugging experience

Operators are Stateless

Why This Feature Will Never Be Implemented in C#

Conclusion

Domain Services in DDD: Navigating Through Validation and Dependency Management

DDD Trilemma: A Crucial Tradeoff in Design

Making Decisions Based on Queries

Simplifying Decisions: Two Robust Rules

F# Discriminated Unions vs. C# Class Hierarchies: A Design Perspective

Is it necessary to confirm inventory before processing payment?

Can we ship an order prior to receiving payment?

And what if a delivered order needs to be canceled?

Problem statement

Discriminated Unions

"Closed" Type Hierarchies

Control Flow

Concluding Thoughts

Robust Design through Value Objects in C#

Enriching C# with F# Insights

Bridging the Gap in C#

Revamping the UserContact Class

Revamping the User Class

Conclusion

Eradicating the Primitive Obsession

Adding Constructor

Ensure Invariant

User Contact

Wrapping up

Always Valid — A Myth or a Tangible Reality?

Rich Model

Anemic Model

Unraveling the Origins of the Split

Always Valid — A Myth or a Tangible Reality?

The Problem of Universals

Contextual Validation and Invariant

Debugging Docker Compose Solutions in JetBrains Rider: A Deep Dive

Introduction

Setting Up a Simple Web App Project

The Docker Compose Configuration

Initiating Debugging in Rider

Understanding the Command Rider Uses

Analyzing the Generated Docker Compose File

Troubleshooting: The Issue I Faced

Conclusion

Implementing Simon Brown's Minimal Approach to Software Architecture Documentation

Integration Testing: Devs and QAs

A note about test data

Web Application Factory VS Real HTTP Calls - Take Two

Applying Template Method Pattern

Configuring Mocks

What if I don’t want to share some tests

A note on modular architecture

Expression Trees + Web Application Factory = ❤️

A brief history of async/await

Why This Feature Will Never Be Implemented in `C#`

Revamping the `UserContact` Class

Revamping the `User` Class