11 KiB
| title | author | description | monikerRange | ms.author | ms.date | uid |
|---|---|---|---|---|---|---|
| Part 7, add search to an ASP.NET Core MVC app | wadepickett | Part 7 of tutorial series on ASP.NET Core MVC. | >= aspnetcore-3.1 | wpickett | 07/24/2024 | tutorials/first-mvc-app/search |
Part 7, add search to an ASP.NET Core MVC app
:::moniker range=">= aspnetcore-9.0"
In this section, you add search capability to the Index action method that lets you search movies by genre or name.
Update the Index method found inside Controllers/MoviesController.cs with the following code:
The following line in the Index action method creates a LINQ query to select the movies:
var movies = from m in _context.Movie
select m;
The query is only defined at this point, it has not been run against the database.
If the searchString parameter contains a string, the movies query is modified to filter on the value of the search string:
The s => s.Title!.ToUpper().Contains(searchString.ToUpper()) code above is a Lambda Expression. Lambdas are used in method-based LINQ queries as arguments to standard query operator methods such as the xref:System.Linq.Enumerable.Where%2A method or Contains (used in the code above). LINQ queries are not executed when they're defined or when they're modified by calling a method such as Where, Contains, or OrderBy. Rather, query execution is deferred. That means that the evaluation of an expression is delayed until its realized value is actually iterated over or the ToListAsync method is called. For more information about deferred query execution, see Query Execution.
[!NOTE] The xref:System.Data.Objects.DataClasses.EntityCollection%601.Contains%2A method is run on the database, not in the C# code. The case sensitivity on the query depends on the database and the collation. On SQL Server,
Containsmaps to SQL LIKE, which is case insensitive. SQLite with the default collation is a mixture of case sensitive and case INsensitive, depending on the query. For information on making case insensitive SQLite queries, see the following:
Navigate to /Movies/Index. Append a query string such as ?searchString=Ghost to the URL. The filtered movies are displayed.
If you change the signature of the Index method to have a parameter named id, the id parameter will match the optional {id} placeholder for the default routes set in Program.cs.
Change the parameter to id and change all occurrences of searchString to id.
The previous Index method:
The updated Index method with id parameter:
You can now pass the search title as route data (a URL segment) instead of as a query string value.
However, you can't expect users to modify the URL every time they want to search for a movie. So now you'll add UI elements to help them filter movies. If you changed the signature of the Index method to test how to pass the route-bound ID parameter, change it back so that it takes a parameter named searchString:
Open the Views/Movies/Index.cshtml file, and add the <form> markup highlighted below:
The HTML <form> tag uses the Form Tag Helper, so when you submit the form, the filter string is posted to the Index action of the movies controller. Save your changes and then test the filter.
There's no [HttpPost] overload of the Index method as you might expect. You don't need it, because the method isn't changing the state of the app, just filtering data.
You could add the following [HttpPost] Index method.
The notUsed parameter is used to create an overload for the Index method. We'll talk about that later in the tutorial.
If you add this method, the action invoker would match the [HttpPost] Index method, and the [HttpPost] Index method would run as shown in the image below.
However, even if you add this [HttpPost] version of the Index method, there's a limitation in how this has all been implemented. Imagine that you want to bookmark a particular search or you want to send a link to friends that they can click in order to see the same filtered list of movies. Notice that the URL for the HTTP POST request is the same as the URL for the GET request (localhost:{PORT}/Movies/Index) -- there's no search information in the URL. The search string information is sent to the server as a form field value. You can verify that with the browser Developer tools or the excellent Fiddler tool.
The following image shows the Chrome browser Developer tools with the Network and Headers tabs selected:
The Network and Payload tabs are selected to view form data:
You can see the search parameter and XSRF token in the request body. Note, as mentioned in the previous tutorial, the Form Tag Helper generates an XSRF antiforgery token. We're not modifying data, so we don't need to validate the token in the controller method.
Because the search parameter is in the request body and not the URL, you can't capture that search information to bookmark or share with others. Fix this by specifying the request should be HTTP GET in the form tag found in the Views/Movies/Index.cshtml file.
Now when you submit a search, the URL contains the search query string. Searching will also go to the HttpGet Index action method, even if you have a HttpPost Index method.
Add Search by genre
Add the following MovieGenreViewModel class to the Models folder:
The movie-genre view model will contain:
- A list of movies.
- A
SelectListcontaining the list of genres. This allows the user to select a genre from the list. MovieGenre, which contains the selected genre.SearchString, which contains the text users enter in the search text box.
Replace the Index method in MoviesController.cs with the following code:
The following code is a LINQ query that retrieves all the genres from the database.
The SelectList of genres is created by projecting the distinct genres (we don't want our select list to have duplicate genres).
When the user searches for the item, the search value is retained in the search box.
Add search by genre to the Index view
Update Index.cshtml found in Views/Movies/ as follows:
Examine the lambda expression used in the following HTML Helper:
@Html.DisplayNameFor(model => model.Movies![0].Title)
In the preceding code, the DisplayNameFor HTML Helper inspects the Title property referenced in the lambda expression to determine the display name. Since the lambda expression is inspected rather than evaluated, you don't receive an access violation when model, model.Movies, or model.Movies[0] are null or empty. When the lambda expression is evaluated (for example, @Html.DisplayFor(modelItem => item.Title)), the model's property values are evaluated. The ! after model.Movies is the null-forgiving operator, which is used to declare that Movies isn't null.
Test the app by searching by genre, by movie title, and by both:
:::moniker-end