A list of items in Javascript/Typescript is simply an array. In chrome debugger with a breakpoint set it looks like this.
In Typescript/Javascript
let list = ["one","two","three"]
But what happens on the ASP.NET Core 3.1 side where binding happens prior to entry into the endpoint?
We want a field with a property which is a List so the run-time model binder will produce an instance of the list.
public List<string> CurrentValues { get; set; }
The Asp.NET binder converts the post information into a class instance of which we can easily see and manipulate the fields.
The entry to the endpoint:
public IActionResult PutSettings([FromBody] Model.Setting settingModel){
//do stuff here
var changes = settingModel.CurrentValues
}
Where settingModel contains a property of type List
EF layer
The EF layer is a bit more complex because by default the proper way to store a list of anything is in a single table. Lists in SQL are a single table usually. So how do we accomplish this? Our containing table of "things" must have a property referring to the table of the list each list item with a pointer back to the container... what?
Consider this:
Table Name = Container
ID = Created by DB automatically.
List = StoreOurLists where FK = this ID.
Table Name = StoreOurLists has rows like this:
ID = Created by DB automatically
Value = "one"
FK = Pointer to the container...
FK = Foreign Key. Note: in code first; you must manually set up the builder.Entity bindings. A somewhat complex arrangement (for beginners).
In the end; storing documents is far easier than this. Is SQL still reasonable for web based lists and data? I think it's time is fading. There's no denying the ease of use with JSON data transfer.
JWP2020
Top comments (0)