Can I inherit from something in my interface, to give me access to HttpContext and return Ok stuff?

[Nefcanto]

I want to create an interface with default methods to share it between my controllers. Let's say it's called IExcelExporter.

public interface IExcelExporter
{
    [HttpGet]
    public IActionResult Export()
    {
         // code needs access to HttpContext and needs access to special results like JsonResult
    }
}

What options do I have to access HttpContext and other required stuff for the web here?

[davidfowl]

Declare the HttpContext as a settable property and make sure it gets set? I'm not sure what you are trying to model, but it doesn't work. Those method exist on ControllerBase.

[Nefcanto]

@davidfowl, I'm trying to use composition in our API layer with minimal boilerplate code. The main discussion is here.

We can't have a fat God-object base class to inherit from. Let's say I want to create a controller that represents a tree, caches the output, needs to be behind the sign-in, and is searchable. Let's call it StaffController. I wish we could create these interfaces ITreeController, ICacheableController, IAuthenticatedController and ISearchableController and we could mix generics with default methods to make the StaffController this way:

public class StaffController : ITreeContrller<Staff>, ICacheableController<Staff>, IAuthenticatedController, ISearchableController<Staff>
{
    // no boilerplate code here to implement them one by one and repetitively for many controllers
}

[davidfowl]

In your ideal situation, how do you introduce the new search capabilities into the 500 APIs? What is the gesture?

[Nefcanto]

@davidfowl, these are real examples I give you from our React code:

return <List
     entityType="Customer"
     hasSearch
     viewable
     separateRowForActions
     multicolumn
/>

Lots of small boolean props, to inject behavior into a list. We say entityType='Customer' and that automatically gives us the CRUD endpoints. We say hasSearch and it puts a box above the list, that box is well designed to have debounce effect, and it sends the term to the endpoint that is there by convention because of the entityType prop.

We say it's viewable and that adds an action to the end of each row with an eye icon to see the entire record (some fields are not shown in table).

We compose truly. Now let's say I want the search box to support autocomplete. A new behavior/feature. I update the base, and no developer needs to touch anything or write even one character. That's true business value.

I want to be able to have the same syntax in C#. PHP has it as traits. Their syntax is very good. Ruby mixin syntax is also very good.

[Nefcanto]

@davidfowl, how about this syntax?

composable Search<T> where T class, new()
{
    [HttpGet]
    public SearchResult Search()
    {
        var term = HttpContext.Request.Query["search"]; // this code won't break the compiler.
    }
}

and

public class FlowerController : ReadWriteController<Flower>
{
     compose from Search<Flower>;
}

No need to implement Search like interfaces, no need to rewrite the method to expose an internal object (current composition model in C#),

The resulting code would become this code before compilation:

public class FlowerController : ReadWriteController<Flower>
{
    [HttpGet]
    public SearchResult Search()
    {
        var term = HttpContext.Request.Query["search"]; // this code won't break the compiler.
    }
}

It's not a well-thought syntax. Just something to start with.

[davidfowl]

So you're still updating 500 react components right? But it's declaring the behavior not copying and pasting the logic. Is that right?

This nerd sniped me a little, so I spent some time playing with minimal APIs because they are a bit more flexible 😄:

using Microsoft.AspNetCore.Http.HttpResults;

var builder = WebApplication.CreateBuilder(args);

var products = new Product[]
{
    new() { Name = "Apple", Description = "A red fruit", Price = 1.00m },
    new() { Name = "Banana", Description = "A yellow fruit", Price = 0.50m },
    new() { Name = "Orange", Description = "An orange fruit", Price = 0.75m }
};

var categories = new Category[]
{
    new() { Name = "Fruit", Id = 1 },
    new() { Name = "Vegetable", Id = 2 }
};

builder.Services.AddSingleton<IRepository<Product>>(new ProductRepository(products));
builder.Services.AddSingleton<IRepository<Category>>(new CategoryRepository(categories));

var app = builder.Build();

app.MapGroup("products")
   .MapApi<ProductApi, Product>();

app.MapGroup("categories")
   .MapApi<CategoryApi, Category>();

app.Run();

static class ApiExtensions
{
    public static void MapApi<T, TModel>(this IEndpointRouteBuilder routes)
        where T : new()
    {
        T instance = new();

        if (instance is ISearchable<TModel> searchable)
            routes.MapGet("search", searchable.Search);

        if (instance is IPageable<TModel> pageable)
            routes.MapGet("/", pageable.GetPage);
    }
}

class ProductApi : ISearchable<Product>, IPageable<Product>
{
    // Override the default implementation
    public Ok<List<Product>> GetPage(IRepository<Product> repository, int page = 1, int pageSize = 10)
    {
        return TypedResults.Ok(repository.GetPage(page, pageSize));
    }
}

class CategoryApi : ISearchable<Category>, IPageable<Category>
{

}

interface ISearchable<TModel>
{
    public Ok<List<TModel>> Search(IRepository<TModel> repository, string query)
        => TypedResults.Ok(repository.Search(query));
}

interface IPageable<TModel>
{
    public Ok<List<TModel>> GetPage(IRepository<TModel> repository, int page = 1, int pageSize = 10)
        => TypedResults.Ok(repository.GetPage(page, pageSize));
}

interface IRepository<T>
{
    List<T> GetPage(int page, int pageSize);
    List<T> Search(string term);
}

public class Product
{
    public required string Name { get; set; }
    public required string Description { get; set; }
    public decimal Price { get; set; }
}

public class Category
{
    public required string Name { get; set; }
    public decimal Price { get; set; }

    public int Id { get; set; }
}

public class ProductRepository(Product[] products) : IRepository<Product>
{
    public List<Product> GetPage(int page, int pageSize) =>
        products.Skip((page - 1) * pageSize).Take(pageSize).ToList();

    public List<Product> Search(string term) =>
        products.Where(p => p.Name.Contains(term) || p.Description.Contains(term)).ToList();
}

public class CategoryRepository(Category[] categories) : IRepository<Category>
{
    public List<Category> GetPage(int page, int pageSize) =>
        categories.Skip((page - 1) * pageSize).Take(pageSize).ToList();

    public List<Category> Search(string term) =>
        categories.Where(c => c.Name.Contains(term)).ToList();
}

[Nefcanto]

@davidfowl, that's the exact point. I don't update 500 react lists. I only update the core and 500 react lists would get the new behavior the next time they are run in the dev mode or published. That's exactly what I want to be able to create for the .NET projects. I will give it a try. Thank you.

[XGavinp]

In ASP.NET Core, default interface methods cannot directly access HttpContext or return specific types like IActionResult. Default interface methods are primarily for providing default implementations for interface members, and they don't have access to instance-specific data like HttpContext.

In your controllers, you can inject IExcelExporter and use the extension method:

    public class MyController : ControllerBase
{
private readonly IExcelExporter _excelExporter;

public MyController(IExcelExporter excelExporter)
{
    _excelExporter = excelExporter;
}

[HttpGet]
public async Task<IActionResult> Export()
{
    return await _excelExporter.ExportAsync(HttpContext);
}
}

[Nefcanto]

@XGavinp, that's exactly the problem. Tons of boilerplate for a simple composition requirement and very little maintenance value and change flexibility. Please see my arguments here. Multiply those 5 or more boilerplate codes by 500 APIs and you definitely realize how inefficient this syntax is.

And please don't become sad by my sad or angry words. I'm thankful for your help. I'm just tired of .NET team refusing to add a graceful composition capability to .NET.

[davidfowl]

Code generation is a viable strategy to reducing boilerplate code as well.

[Nefcanto]

@davidfowl, you're true. We do have code generation. We have a small headless CMS. This means that we are JSON-first. We define our schemas (our domain) in JSON and based on that we create our models and our EF Core code and data access code and a couple of other things.

The thing is that we do it to create the entire things I mentioned. That's easy. Delete the old one and create a new one using string concatenation. Feasible, maintenable, cheap.

The problem is that we need to add code to existing code. We need to add search capability to an existing controller.