A typical workflow for showing stuff from a database on a UI goes like this: get information from database. Map info to a data model in code. Display data model in UI.
Okay, that's a big oversimplification. But even describing the workflow like that, it's easy to see how things might be replicated in code, and a programmer might find the same things being typed in more than once.
If a lot of data is being pulled and displayed, the total amount of time spent balloons, since things are typed once to pull from the database, again to set up the data model object properly to mirror the data from the database, and a third time to bind/hook up into the UI.
Enter
href='https://docs.microsoft.com/en-us/dotnet/api/system.dynamic.expandoobject'>ExpandoObject"}.This class imitates what might otherwise be done with reflection and meta programming. In other words, the data model's structure is dynamic, not defined by hard-coded member names and types.
To explain, consider this code:
dynamic viewModel = new ExpandoObject();
using (var reader = cmd.ExecuteReader()) {
while (reader.Read()) {
// add fields from database to view model
for (int i = 0; i < reader.FieldCount; i++) {
((IDictionary, object>)viewModel).Add(reader.GetName(i), reader.GetValue(i));
}
...
What's going on here? The view model (or data object) is an ExpandoObject. Rather than hard-code in the names and types of the properties, the code loops through every column in the database results and automatically forms the ExpandoObject to match what is needed.
From there, you will still have to show the UI. But this is simplified by using a binding with the same name as the database column:
<Label Content="{Binding REQUESTED_BY}" />