1. P.527/748, Exercise 4. I'm really unclear about the "DataKeyNames" aspect of this solution. What exactly is the DataKeyNames attribute? I don't recall any previous explanation.
Data-bound controls keep track of the primary keys of data objects in ViewState. For example, by assigning something like "Id" to the DataKeyNames property, the GridView control tracks all Ids of the records or objects assigned to it in ViewState, enabling you to do stuff like Selecting, Updating and Deletion of rows. For more info:
DataKeyNames on Google
2. General: I don't understand how one determines whether to use the EntityDataSource events versus, for example, the ListView events to fire code.
If often depends on what you need to do. As I showed in the book, some stuff can be done only on the data source (such as accessing a strongly typed item such as a Genre entity), while others are better handled by the data controls. The API documentation for the events on the MSDN site should give you a better idea of their capabilities.
3. General: I also don't really understand the difference between "loosely typed" and "type inference". Coming from a Classic ASP background, your definition of "type inference" seems to describe exactly what happens with "loosely typed" variables in vbscript: the system figures out the datatype all by its little self, real smart-like. Exact same thing. No?
Close, but no cigar. The biggest difference is *when* the type is inferred and whether you can change it afterward ir not. In a strongly typed language (such as C# and VB
), type inference takes place at *compile* time. Once the type is inferred, it cannot be changed. This guarantees type-safety which can help write better and more robust applications. Consider this example:
The compiler will infer myAge as an int, as 39 is an integer. This is identical to writing it like this:
(Sidenote: I prefer to not use var for these scenarios. I find that "int myAge" is much easier to read. However, var was introduced for a reason: some types cannot be expressed explicitly (such as anonymous types), in which case var is the only way to define them. When using LINQ, var is often used - and needed - a lot.)
Once a type is inferred, it cannot be changed. E.g. you can't change the inferred type, nor the value assigned to it. That means that the following fails:
var myAge = 39;
myAge = "Thirty-nine";
This fails, because "Thirty-nine" cannot be cast to an int. Since myAge has been inferred as a strongly typed int, this code fails.
In weakly typed languages, inference takes place at run time. In classic ASP, this works fine:
myAge = 39
myAge = "Thirty-nine"
In a weakly typed language the type is inferred at run-time by looking at the value assigned to it.
Does this help?