DEV Community: Bojan Veljanovski

Use Enums Over Booleans for Status Fields

Bojan Veljanovski — Wed, 23 Apr 2025 07:07:15 +0000

In business applications, we often need to track the state of entities - users, orders, payments, etc. While boolean flags might seem simple, they often lead to maintenance headaches. Here's why you should consider using enums instead.

1: The meaning of false is not always clear

The meaning of false is not always clear when using Booleans for status fields.

Let's see this example:

public class User
{
    public bool IsActive { get; set; }
}

What does it mean when IsActive is false? Does that mean the user has been banned? Or is the email not yet verified?
In most such situations, choosing Enum is a much better choice. Enums are more descriptive and flexible.

Let's refactor:

public enum UserStatus
{
  Active,
  PendingVerification
}
 
public class User
{
  public UserStatus Status { get; set; }
}

Now you know that the user can be in active or pending verification state. This approach makes the meaning of the user's states obvious.

2: Expanding with a third option is a very challenging refactor

Adding a third state like “Banned,” using Booleans can get problematic. Let's see this example:

public class User
{
  public bool IsActive { get; set; }  // from the original example
  public bool IsBanned { get; set; }  // newly added state for handling banned users
}

This approach creates four possible combinations, but only two are valid. Managing these relationships can become complicated very quickly. Can an active user be banned? What happens then - what field takes precedence?

Additionally, what about existing data? We need to change the DB schema and migrate a lot of data to the new schema, which may create downtime or technical hurdles, especially at scale.

With Enums, adding a new state is simple:

public enum UserStatus
{
  Active,
  PendingVerification,
  Banned  // new state
}

Rules of thumb

Here are some rules of thumb that I use:

Start with an enum if there’s any chance you’ll need more than two states in the future.
Use boolean flags only for clear yes/no scenarios that are unlikely to change.
Before adding a boolean flag, ask yourself: “Could this need more states down the road?”

Using enums over booleans early for potentially expandable status fields ensures easier maintenance and clearer code in the long run. I won't consider it as over-engineering.

Get Current User Outside an ASP.NET Controller

Bojan Veljanovski — Sun, 03 Jan 2021 14:10:26 +0000

You can access the currently authenticated user from a controller action method in the following way:

[Route("[controller]")]
public class InternalController : ControllerBase
{
  [HttpGet]
  [Authorize]
  public string GetCurrentUser()
  {
    return base.User.Identity.Name;
  }
}

To access it outside the controller, for example in a MediatR handler, you need to inject and use the IHttpContextAccessor service, which is already provided by ASP.NET:

[Route("[controller]")]
public class InternalController : ControllerBase
{
  private readonly IMediator _mediator;

  public InternalController(IMediator mediator) 
  {
    _mediator = mediator;
  }

  [HttpGet]
  [Authorize]
  public async Task<string> GetCurrentUser()
  {
    var response = await _mediator.Send(new GetCurrentUser.Request());
    return response.CurrentUserName;
  }
}

public class GetCurrentUser
{
  public class Request : IRequest<Response> { }

  public class Response 
  { 
    public string CurrentUserName { get; set; }
  }

  public class Handler : IRequestHandler<Request, Response>
  {
    private readonly IHttpContextAccessor _httpContextAccessor;

    public Handler(IHttpContextAccessor httpContextAccessor)
    {
      _httpContextAccessor = httpContextAccessor;
    }

    public Task<Response> Handle(Request request, CancellationToken cancellationToken)
    {
      return Task.FromResult(new Response 
      { 
        CurrentUserName = _httpContextAccessor.HttpContext.User.Name
      });
    }
  }
}

Finally, to make this work, you need to register the IHttpContextAccessor dependency in your Startup class:

// ConfigureServices
services.AddHttpContextAccessor();

Select N+1 Problem

Bojan Veljanovski — Thu, 02 Jan 2020 00:08:36 +0000

Select N+1 is a data-access performance problem. Any code that iterates thru a collection of elements, and executes additional query for each element, has this problem. Thought, this behavior is avoidable.

Let's look at this sample code:

var books = LoadBooks();        // 1st query
foreach (var book in books)
{
    var bookReviews = LoadBookReviews(book.Id);    // 2nd query, called N times
    // ...
}

LoadBooks() makes a database query to load books. Then, for each book LoadBookReviews(book.Id) makes a query to load reviews for the given book. Loading books is one query, plus N additional queries for loading book reviews, results in N+1 database queries, where N is the number of books.

If there are 100 loaded books, the above code will call 101 database queries, thus causing performance problems. Imagine if multiple users open the same page at the same time...

How does this look in SQL?

-- 1st query
SELECT * FROM Book ...

-- 2nd query, N times
SELECT * FROM BookReview WHERE BookId = 1    -- BookId = @BookId
SELECT * FROM BookReview WHERE BookId = 2
SELECT * FROM BookReview WHERE BookId = 3
...

Solution: Load necessary data before iterating through it

One solution to N+1 problem is to load all necessary data before iterating through it. This way we won't need to execute additional database queries to load child data in for-loops, since we will have that data loaded before.

var books = LoadBooks();        // 1st query
var reviews = LoadBookReviewsFor(books.Select(x => x.Id)); // 2nd query, called once
foreach (var book in books)
{
    var bookReviews = reviews.FirstOrDefault(x => x.BookId == book.Id);
    // ...
}

LoadBooks() does the same thing as before, where LoadBookReviewsFor(..book ids..) queries the database to load all book reviews for a given list of books, instead for a single book.

In this case, no matter how many books or reviews are there, the code will always call only 2 database queries; thus fixing the N+1 problem.

How does this look in SQL?

-- 1st query
SELECT * FROM Book ...

-- 2nd query
SELECT * FROM BookReview WHERE BookId IN (1, 2, 3, ...)   -- BookId IN @BookIds

Example in Entity Framework with navigation properties and lazy loading

Bad:

var books = dbContext.Books.ToList();    // 1st query
foreach (var book in books)
{
    var bookReviews = book.Reviews.ToList();    // 2nd query, called N times via lazy loading
    // ...
}

Good: refactor to eager loading, using the Include feature.

var books = dbContext.Books.Include(x => x.Reviews).ToList();    // 1st query, batched
foreach (var book in books)
{
    var bookReviews = book.Reviews.ToList();    // in-memory, no additional queries
    // ...
}

By using .Include(x => x.Reviews) in Entity Framework (or .Fetch(x => x.Reviews) in NHibernate) we eagerly load related book reviews in a single database query. This approach solves the Select N+1 problem, but opens doors to loading too many objects in memory, especially when we need to load many related collections; in such cases, plain old SQL approach is preferred.

Example in Entity Framework without navigation properties

Bad:

var books = dbContext.Books.ToList();    // 1st query
foreach (var book in books)
{
    // 2nd query, called N times explicitelly 
    var bookReviews = dbContext.BookReviews.Where(x => x.BookId == book.Id).ToList();
    // ...
}

Good: load necessary data before iterating through it

var books = dbContext.Books.ToList();            // 1st query
var bookIds = books.Select(x => x.Id).ToArray();
var allReviews = dbContext.BookReviews           // 2nd query
    .Where(x => bookIds.Contains(x.BookId))
    .ToList();

foreach (var book in books)
{
    var bookReviews = allReviews.Where(x => x.BookId == book.Id); // no additional query
    // ...
}

Example in Marten document database

Bad:

var books = session.Query<Book>().ToList();    // 1st query
foreach (var book in books)
{
    // 2nd query, called N times explicitelly 
    var bookReviews = session.Query<BookReview>()
        .Where(x => x.BookId == book.Id)
        .ToList(); 
    // ...
}

Good: same approach, load necessary data before iterating through it

var books = session.Query<Book>().ToList();     // 1st query
var bookIds = books.Select(x => x.Id).ToArray();
var allReviews = session.Query<BookReview>()    // 2nd query
    .Where(x => x.BookId.IsOneOf(bookIds))
    .ToList();                              

foreach (var book in books)
{
    var bookReviews = allReviews.Where(x => x.BookId == book.Id); // no additional query
    // ...
}

Summary

Select N+1 is a performance problem that can really slow down your application. The more "N" results the application has, the less performant it will be when this problem is not detected and fixed.

Here we've seen how to detect such problem and how to fix it. The common approach follows a straightforward practice: load necessary data before iterating through it.

Hi, I'm Bojan Veljanovski

Bojan Veljanovski — Sun, 29 Jan 2017 20:27:54 +0000

I have been coding for [number] years.

You can find me on GitHub as bojanv91

I live in [city].

I work for [company]

I mostly program in these languages: [languages].

I am currently learning more about [topic].

Nice to meet you.