Any software developer should be used to having to learn new libraries or languages, but for me, it’s been a bit extreme. I stopped coding in 1988 when I went into technical management, and I didn’t come back to coding until 2009—that’s a 21-year gap. To say that the landscape had changed is an understatement; I felt like a child on Christmas morning with so many lovely presents I couldn’t take it all in.
I made all the rookie mistakes at the beginning, like thinking object-oriented programming was about using inheritance, which it isn’t. But I learned the new syntax, new tools (wow!), and reveled in the amount of information I could get online. I chose to focus on Microsoft’s stack, mainly because of the wealth of documentation available. That was a good choice at the time, but now with .NET Core and its open source, multiplatform approach, it turns out to be an excellent choice.
The first applications I worked on in 2009 were ones that optimized and displayed healthcare needs geographically, especially around where to locate treatment centers. That required complex math (which my wife provided) and serious database work. I went through ADO.NET, LINQ to SQL, and then in 2013 I swapped to Entity Framework (EF), when EF 5 supported SQL’s spatial (geographical) types.
Entity Framework Core in Action covers all the features of EF Core 2.0, with plenty of examples and lots of code you can run. I’ve also included numerous patterns and practices to help you build robust and refactorable code. The book ends with an entire section, “Using Entity Framework Core in real-world applications,” which shows my focus on building and shipping real applications. And I have not one, but two, chapters on performance tuning EF Core because your users/clients won’t accept a slow
Some of the most pleasurable chapters to write were ones where I solved a technical problem, such as the best way to handle business logic (chapter 4), or performance tuning an application (chapters 13 and 14). These needed a combination of technical knowledge and insight into what business/development problem I was trying to solve. I also present the pros and cons of each approach I use, as I don’t believe there is “silver bullet” answer in software—just a range of compromises that we as developers need to consider when choosing how to implement something.