Book Your Stay at AwesomeHotel! (A C#/.NET/Dapper Hotel Booking App)

Check out this hotel booking app I built with C#/.NET/Dapper, inspired by Tim Corey's C# Masterclass (an awesome class for anyone interested in learning C#: www.iamtimcorey.com). Tim's MVP includes a method for getting the reservations based on the guest's full name, but I modified mine to get the reservation based on a unique GUID - as well as rendering it on the screen at the time of booking.

The user simply chooses their desired dates, clicks on their desired room type, and enters their name to confirm their booking. The data access layer calls some stored procedures, which take care of basic functions such as: Checking to see if the guest's name is in the database and adding it if it's not already there, adding their reservation to the Reservations table, etc. Here I'm simply using my local Microsoft SQL Server.

I've worked on a few C#/.NET/Entity Framework projects at work as well, so I decided to play around with EF and compare Dapper with Entity Framework. Tim Corey is clear that he prefers Dapper, and explains it's easy to cause issues (such as poor performing queries) in Entity Framework if you don't know what you're doing. After learning about this from some senior developers at my company and doing a little hacking and research of my own, it's clear he is right!

I ended up running across this awesome blog by a guy named Brent Ozar. He includes a code snippet in which EF's context saves 449 Stackoverflow posts in memory, then goes to write an additional SQL query for each one to get additional data. Whoa - that's a LOT of SQL queries in one go!

That is highly illogical, captain.

The issue is called a N + 1 issue caused by Entity Framework's Lazy Loading feature, and apparently it's a pretty common problem. It can cause issues which become more noticeable as your database grows. I even found this stackoverflow article from somebody who said their team actually ended up turning off Lazy Loading entirely due to so many n+1 issues. After that, the performance issues caused by n+1's went away, thus they felt living without lazy loading in EF it was 100% worth it.

I've heard it said that 'if your team is pretty good at writing SQL queries, use Dapper, but if your team is weak with SQL, use Entity Framework.' I disagree with this, as I'm learning the importance of monitoring what SQL queries are running under the hood of EF (not to mention a bunch of other things). Either way you go, SQL is good to know (HeY, ThAt RHyMeS!)

Performance issues, begone!

The code lives here: https://github.com/cvs181801/HotelApp1