ASP.NET Core Advanced Series You Don’t Know (3)

ASP.NET Core Advanced Series You Don’t Know (3)

Foreword

I haven’t updated my blog for more than a year. The last time I wrote about this series was four years ago. Although it’s late, it’s late. There is no commitment. It focuses on casualness, so there is no interruption. Urgent update, haha, in the last article we studied the detailed principles from request to binding, this article discusses the details of model binding. When a problem arises and is finally solved, only by looking back can we analyze its background and design ideas as a whole. gained. Okay, without further ado, let’s start the journey of model binding details.

Problem occurs

We define a model and then make a query request. Of course, at this time we recommend explicitly using the query feature, that is, FromQuery reception, on the background controller Action method. The code is as follows

public class UserAddress
 {
     public string  span> Code { get; set; }
 }

[ApiController]
 [Route("  api/[controller]/[action]")]
 public class  span> UserAddressController : ControllerBase
 {
     private readonly  span> ILogger _logger;

     public UserAddressController(ILoggerlogger)
     {
         _logger = logger;
     }

     [HttpGet]
     public IActionResult Get(  [FromQuery] UserAddress address)
     {
         return Ok(address  );
     }
 }

Nothing wrong, next we add an attribute to the defined user address class, as shown below

public class UserAddress
 {
     public string  span> Code { get; set; }
     public string  span> Address { get; set; }
 }

The value cannot be bound. This is a strange situation. Is this an official bug? This is true for us using 6.0 and 7.0. There is no doubt that using . NET 8.0 still has the same result. Here comes the problem. Please think about the reason for a moment and let us continue to analyze

Root cause source code analysis

Through comparison before and after, we can preliminarily analyze that the reason may be one of two aspects or a combination of the two. First, the object attribute address and the receiving object parameter variable address cannot be the same ( (not case-sensitive), secondly, the accepted object parameter variable address and the key name address on the URL cannot be the same (not case-sensitive). We can only analyze this point for the time being. Of course, we will know after a try. As for what the root cause is, next we can only analyze the model binding source code. When it comes to analyzing the source code, some children may not know where to start. Here are the Let’s go through the entire process of analyzing the root causes from 0 for reference for children’s shoes in need. It’s just my personal opinion. Unless you are proficient, you will go through a process. This is inevitable, so don’t doubt anyone.”color: rgba(0, 0, 0, 1)”>.IsNullOrEmpty(propertyName))
{
return prefix ?? string.Empty;
}

if (propertyName.StartsWith(‘[ ‘))
{
// The propertyName might represent an indexer access, in which case combining
// with a ‘dot’ would be invalid. This case occurs only when called from ValidationVisitor.
return prefix + propertyName;
}

return prefix + ” .“ span> + propertyName;
}

Okay, here we just know that the framework does this and the value cannot be bound. The problem arises again. Please think about the original intention and purpose of the framework’s design. What is thought? The framework considered many scenarios for us. We deleted all the above custom implementations. The framework thought that we wanted to achieve the following binding purposes, but we never thought of taking the wrong approach. In fact, we took advantage of a loophole. As the saying goes, you think it is you. What I thought was not what I thought, and then I looked confused

Learn inferences from one example

It’s not over yet, let’s continue the class. After we analyzed the entire cause and effect, we finally understood what the prefix mentioned in the IValueProvider interface specifically means, and then for prefix matching Using the dichotomy algorithm, in the same way, it is not difficult for us to see that the above is object binding processing, and the same is true for collections under the same conditions.

Summary

When performing a query operation, if the key name on the request URL is the same as the background receiving parameter variable name and is not case-sensitive, the framework thinks that we want to use the receiving parameter variable as Prefix is ​​used to bind the value. Under the same conditions, the same is true for collections. Unless we implement a custom set, we must not define them with the same name, otherwise the value will not be bound.

Translation

Search

Copy

What you see is not the thing itself, but the meaning given by interpretation.