I’m going to write today about the dangers of not knowing your software stack and how it fits in with your personal computing setup. When I started this blog series I had not yet graduated from WGU, and had only just finished the Software I project. I also spent a lot of time setting up a container specific workflow that was based on the turnkey solution that I found in the Visual Studio 2017 .NET core templates for new projects. The solution for Docker, in particular, proved to be a problem for my development/personal computer setup at home. You see, Docker for Windows requires you to install Hyper-V; a Type I hypervisor. Type I hypervisors, and Hyper-V in particular, replace a normal host OS with a hypervisor OS dedicated to virtualizing other guest operating systems. Hyper-V for Windows 10, in this case, virtualizes a Windows 10 installation and pretends that you’ve just added Hyper-V to Windows 10 instead of replaced the operating system entirely. This kind of setup is great if you have hardware dedicated to running virtual machines, and you don’t need bare metal performance. However, when you’ve got a beefy gaming rig that you want to play games and do development work on it can cause performance issues on the gaming side of things. All that being said, I’m going to be doing a Docker setup for deployment, but after I’ve finished the app’s core features. To that end, we’re going to talk about ASP.NET core and it’s architecture.

As soon as you run a dotnet new command from the .NET core 2.0 CLI, you’ll get a folder structure of Views that comprise the initial boilerplate Razor views. It looks like this:

Each folder corresponds to a controller. For example, all the views in the Home folder can be accessed by the HomeController in a corresponding method name. So if I have a file called ‘Parts.cshtml’. I can return that view by creating a method called Parts and calling the View() method inside of the Parts method. This will compile and return the HTML that will finally be rendered in the browser when we navigate to localhost/home/parts. The routes to each controller can be defined in a different manner if you’d like, but the default {url}/{controller}/{view-method}/{id?} is definitely the recommended method for URL routes. However, you can add custom routes into the Startup.cs file inside the call to app.UseMvc(); . Finally, we need a way to persist data and .NET core has access to the Entity Framework ORM from ASP.NET MVC.

The Entity Framework allows databases to be configured and used with C# code only. The Entity Framework analyzes C# objects and creates database migrations based on the Model objects. These migrations allow our database to be configured without having to manually build and code the schema in SQL or SQL Server Management Studio. After our migrations have been created we can run them and build out our database by running the dotnet migrate command. Once the migrations have been applied to our database, we can then insert and update data by simply calling methods on our Entity Framework objects. For example, if you’ve made a parts or products class, you can call a save() method after setting properties and fields on the object to apply those changes to the database. This makes it possible to write ASP.NET core apps backed by a SQL database without having to know a large amount of SQL.

I’ve covered the basic MVC pattern and objects associated with the pattern in ASP.NET core. In the next few posts, we’ll finish building our app to save products and parts in a database. I realize that this blog post doesn’t contain any educational content, but over the next few months I’m going to be filling out a full .NET core app and blogging about it. So stay tuned!