Insider Dev Tour ‘review’

On Friday I attended Microsoft’s ‘Insider Dev Tour’ in Melbourne, one of about 44 similar events being held around the world throughout the month of June. Microsoft advertised the event as being ‘for developers interested in building Microsoft 365 experiences (…) today, using the latest dev technologies, as well as for those who want a peek into the future,’ and it was completely free to attend. Hosted at the offices of Xello, a Melbourne-based IT consultancy company, the event was all day, running from the hours of 8 to 5, and had food and coffee provided.

I was fairly excited when I heard about the event, having being recently drawn in to the Windows desktop development ecosystem through my involvement in the Open Live Writer project. I wasn’t going in with any particular agenda on things I would’ve liked to learn, but rather I was just curious as to how the whole day would play out and if I’d pick up any nifty skills. I’ve never been to any kind of developer conference before, so really this would’ve been a first for me.

Continue reading “Insider Dev Tour ‘review’”

C# Dirty Delegate Hack

Just a quick one for today. For a uni C# assignment I’ve had to implement a multi-delegate that processes a list of data, with the delegate consisting of three disparate functions which I also had to implement, according to a unit test spec. Data has to flow between each step of the delegate to produce the correct output. Now the usual way to do this would be to use pass-by-reference to alter the original data in-place, however in this circumstance it was not possible as the tests required the signatures of the delegate methods to pass-by-value. After thinking for some time, I came to the following solution. Beware, it’s fairly horrible.

In the classes containing the delegate methods, I define a helper function;

public static List<List<string>> S(List<List<string>> oldData, List<List<string>>newData) {
     for (var i = 0; i < oldData.Count; i++) oldData[i] = newData[i];
     return oldData;
}

Then in the delegate methods, I wrap the results expression in this helper function, passing the original list as the first parameter

public List<List<string>> StripWhiteSpace(List<List<string>> data)
     => S(data, data.Select(row => row.Select(val => val.Trim()).ToList()).ToList());

This then results in the new data being returned from the method (satisfies the tests) as well as the original data being replaced (allows the data to flow to the next delegate method). How does it work? It comes down to the fact that the data I’m working with here is non-primitive; passing it between methods is implicitly by reference rather than by value. It did take me a while to reach this conclusion, my initial thinking was that I’m working with lists of strings, and strings are primitive and therefor pass-by-value. When I realised I was actually working with Lists, which are non-primitive objects, it occurred to me that I could write a helper method to modify each member of the original List in-place. Because the new data is being placed back into the original List object, the same object of which is referenced later on, the data carries itself forward into those next methods of the delegate.

Dealing with composite primary keys and EntityFramework scaffolded controllers

A recent uni assignment has required me to implement an ASP.NET Core REST API using EntityFrameworkCore on a pre-existing database. Whilst EF Core tends to generate controllers for models with single primary keys just fine, I’ve found that it has no support for composite primary keys. This requires you to alter your controller classes to add the support manually, which in my case involved the following;

  • Alter the paths of the individual Get, Put, and Delete endpoints to contain two (or more, depending on how many keys are in your composite) parameters, and then alter the method parameters to match. This requires careful consideration as there are many different ways you can structure the parameters in your route.
  • Alter every usage of _context.nameOfModelHere.FindAsync to contain all components of your primary key. Look at the model’s Entity definition in your database context class, specifically the usage of entity.HasKey, to determine the order in which to list the components in your key to FindAsync.
  • Alter the nameOfModelHereExists method to take the correct amount of parameters for your key. Adjust the body of the method accordingly to check all parts of the key; I just added && at the end of the existing equality expression, and added more equality expressions.
    • Alter all usages of nameOfModelHereExists appropriately.
  • In the Put method, alter the second if statement to check all the components of your primary key, rather than just id.
  • In the Post method, adjust the CreatedAtAction call in the return statement to contain all the components of your primary key.
  • I would also recommend updating all the auto-generated comments that EntityFramework put in to keep things consistent.

Continue reading “Dealing with composite primary keys and EntityFramework scaffolded controllers”