Same query multiple times executed defered execution - asp.net-mvc

Question

I'm building a very simple CRUD web-application (ASP.NET MVC) for tennisplayers and the tournaments they can participate.
On a specific page I want to show all tournaments in the database with a title at the top saying 'All Tournaments' with between brackets the amount of records in the database.
My cshtml would look like this:
#model System.Collections.Generic.IEnumerable<TMS.BL.Domain.Tournament>
#{
ViewBag.Title = "All Tournaments";
Layout = "_Layout";
}
<h3>All Tournaments (#Model.Count())</h3>
#if (!#Model.Any())
{
<p>No tournaments were found...</p>
}
else
{
<table class="table">
<thead>
<tr>
<th scope="col">Name</th>
<th scope="col">Starts</th>
<th scope="col">Ends</th>
<th scope="col">Org. Club</th>
<th scope="col"></th>
</tr>
</thead>
<tbody>
#foreach (var t in Model)
{
<tr>
<td>#t.Name</td>
<td>#t.StartDate.ToString("ddd, dd/MM/yyyy")</td>
<td>#t.EndDate.ToString("ddd, dd/MM/yyyy")</td>
<td>#t.OrganizingClub.Name (#t.OrganizingClub.Province - #t.OrganizingClub.Town)</td>
<td>
<a asp-controller="Tournament" asp-action="Details" asp-route-id="#t.Id" class="btn btn-primary btn-sm">Details</a>
</td>
</tr>
}
</tbody>
</table>
}
}
The controller for this page is the TournamentController. This controller is using a Manager object which contains the dbcontext. The GetAllTournamentsWithOrgClubAndParticipants() method returns an IEnumerable of tournament objects (with an include of the club and pariticpants, but for my question this is of no importance).
public class TournamentController : Controller
{
private IManager _mgr;
public TournamentController(IManager manager)
{
_mgr = manager;
}
public IActionResult Index()
{
return View(_mgr.GetAllTournamentsWithOrgClubAndParticipants());
}
When I load the page, I see that the same query is fired 3 times. once for the #Model.Count() in the title of the webpage, once for the #Model.Any() to determine wheter or not to show the table and once in the foreach loop. Now I know this is because of defered excecution and I could resolve this by adding a ToList() behind the GetAllTournamentsWithOrgClubAndParticipants() in the controller class, but I often hear NOT TO USE the ToList() method because of the way you are loading everything into memory doing this. To my feeling for this case it's still better than excecuting the same query 3 times in a row or am I wrong? Any other way I could resolve this?
Thank you very much!

Answer 1

By returning IEnumerable you are telling the caller that it will get something that can be enumerated over, it does not set the underlying type. So for instance if your manager/repository method returns:
var result = context.Tournaments.Include(t => t.OrganizingClub).Include(t => t.Participants);
return result;
then what is sent back is effectively an EF Query that can be enumerated over. Your Razor code-behind will effectively execute it each time to get the Count, Any, and then to iterate over with your foreach. This should execute 3 slightly different queries. The first being a SELECT COUNT(*) FROM... the second being a IF EXISTS SELECT TOP (1) FROM... then the SELECT t.Id, t.Name, ... FROM with the same filters and joins.
Changing this to:
var result = context.Tournaments.Include(t => t.OrganizingClub).Include(t => t.Participants).ToList();
Will load the details into memory once, then the Count and Any will just be in-memory operations. This in itself for this example is not bad, but it is worth understanding the potential consequences of operations like this. When you're dealing with a data volume that will be manageable on a single screen (I.e. 10's of records, not 1000's+) then there is essentially no harm in returning a materialized list of data. However, as systems grow, design decisions based on smaller data sets can come back to bite you in the butt. For instance, if you want to introduce pagination for results. You'll want the population to the view to be running a query that ultimately loads and returns just one page of data, not loading all rows to send one page to the view.
Even with dealing with smaller sets of data it is worthwhile to understand and utilize EF's projection capability using Select to populate view models. In your example you will be loading all data from the Tournament, OrganizationClub, and Participants even though your view only needs a handful of fields. This can also open the door for unexpected future performance hits because you are serializing entities. If we later add another navigation property or collection to a Tournament, Club etc. and even if this view doesn't need that additional property/collection, simply sending a Tournament to the view could result in the serializer "touching" that navigation property and triggering a lazy load. (Extra queries) All the sudden a new requirement for one area of the application has a performance impact in many other areas you didn't even touch.
Looking at the View code:
<td>#t.Name</td>
<td>#t.StartDate.ToString("ddd, dd/MM/yyyy")</td>
<td>#t.EndDate.ToString("ddd, dd/MM/yyyy")</td>
<td>#t.OrganizingClub.Name (#t.OrganizingClub.Province - #t.OrganizingClub.Town)</td>
<td>
<a asp-controller="Tournament" asp-action="Details" asp-route-id="#t.Id" class="btn btn-primary btn-sm">Details</a>
</td>
We need a Tournament Name, Startdate, EndDate, Organizing Club Name, Province, and Town, plus the Tournament ID.
This can be simplified down to a minimal view model called for example TournamentSummaryViewModel:
[Serializable]
public class TournamentSummaryViewModel
{
public int Id { get; set; }
public string Name { get; set; }
public DateTime StartDate { get; set; }
public DateTime EndDate { get; set; }
public string OrganizingClubName { get; set; }
public string ClubProvince { get; set; }
public string ClubTown { get; set; }
}
then to project this:
var result = context.Tournaments
.Select( t => new TournamentSummaryViewModel
{
Id = t.Id,
Name = t.Name,
StartDate = t.StartDate,
EndDate = t.EndDate,
OrganizingClubName = t.OrganizingClub.Name,
ClubProvice = t.OrganizingClub.Province,
ClubTown = t.OrganizingClub.Town
}).ToList();
The advantages of this is that it minimizes the query to just the columns the view will need. This avoids surprises as the data model changes/grows over time as we don't serialize entities so there are no lazy load risks. When using projection with Select (Or Automapper's ProjectTo) you don't even need to worry about eager loading /w Include. It also reduces the payload size to the view, and helps hide the overall domain structure of your application from people peeking and even tampering with the data being sent via browser debugging tools.
In the above example we just issue the ToList() call on the assumption that the data volume will be reasonable, but we could just as easily let it return the IQueryable for the Razor code to interact with. You can map fields to flatten data (such as adding details from the OrganizingClub) or consolidate data such as if you want ParticpantCount = t.Paricipants.Count(), or nest additional view models Selected from related data. The key is to avoid embedding the entities themselves in the returned ViewModel. (As they can form a ticking time bomb.)