Hey there! Glad you got both approaches working for your form submission logic. Let's break down how Request.Form and IFormCollection differ, and which one makes more sense for your project.

Core Differences #

• Direct Access vs Framework-Provided Binding
  • Request.Form is a property of the HttpRequest object, giving you direct, low-level access to the form data collection. Under the hood, it actually returns an IFormCollection instance in ASP.NET Core.
  • IFormCollection is a dedicated interface for encapsulating form data, delivered to your controller method via model binding—this is the standard, framework-designed way to grab form inputs in MVC/Core.
• Testability & Maintainability
  • Using IFormCollection as a controller parameter makes unit testing way easier: you can just construct a mock IFormCollection and pass it directly to your method, no need to simulate the entire HttpRequest object.
  • With Request.Form, testing requires mocking the full request context, which adds unnecessary complexity.
• Clarity & Separation of Concerns
  • IFormCollection explicitly declares that your controller method depends on form data, aligning with MVC's focus on separation of concerns. It's immediately clear to other developers where the input is coming from.
  • Request.Form bypasses the model binding system, making the code less intuitive and harder to follow for someone reading it later.
• Safe Value Retrieval
  • Both let you safely access values (e.g., TryGetValue), but IFormCollection makes this pattern more straightforward as a dedicated parameter, rather than digging into the Request object.

Which Should You Use? #

Stick with IFormCollection as your controller parameter for most form submission scenarios. Here's why:

1. It follows ASP.NET Core's best practices for model binding, making your code more maintainable and idiomatic.
2. It simplifies unit testing, which is a big win for long-term project health.
3. It keeps your controller methods clean and focused, with clear dependencies declared upfront.

That said, Request.Form isn't "bad"—it's useful if you need to access other parts of the request alongside form data, but for standard form handling, IFormCollection is the better choice.

Bonus: Even Better Approach—Strongly Typed Model Binding #

For an even cleaner, more type-safe solution, consider using a dedicated model class instead of IFormCollection. Here's how:

First, create a simple model for your search input:

public class AirlineSearchInput
{
    public string Airline { get; set; }
}

Then update your controller method to accept this model:

[HttpPost]
public async Task<IActionResult> Index(AirlineSearchInput searchInput)
{
    if (!string.IsNullOrEmpty(searchInput.Airline))
    {
        var bagsResult = await GetAllFromDatabase(searchInput.Airline);
        if (bagsResult is OkObjectResult okResult && okResult.Value is List<Bagsmvc> bagList)
        {
            return View(bagList);
        }
    }
    return View(new List<Bagsmvc>());
}

This approach eliminates magic strings (like "Airline" in your indexer calls), gives you compile-time type checking, and makes your code even more readable. It's the gold standard for form handling in ASP.NET MVC/Core.

Quick Optimisation for Your Current Code #

If you want to stick with IFormCollection, here's a safer version of your controller method that handles missing parameters gracefully:

// Post: Bags
[HttpPost]
public async Task<IActionResult> Index(IFormCollection collection)
{
    if (collection.TryGetValue("Airline", out var airlineValues))
    {
        string airline = airlineValues.ToString();
        var bagsResult = await GetAllFromDatabase(airline);
        
        if (bagsResult is OkObjectResult okResult && okResult.Value is List<Bagsmvc> bagList)
        {
            return View(bagList);
        }
    }
    
    // Return empty list if no valid search term was provided
    return View(new List<Bagsmvc>());
}

内容的提问来源于stack exchange，提问作者Steve Silberberg