Welcome back! I apologize for being gone for the last couple of months, but I have moved!! I absolutely loved working at Quicken Loans, but I missed my family in Texas, so my wife and I have relocated to Austin. In that time, we have both started new jobs!
So, now that I am a bit more settled, I wanted to continue with this series because I think it is very relevant. It seems to me that job interviews for software engineers are becoming more intense (based on my recent experience). The level of ‘stuff’ you need to know to land a good gig keeps increasing and makes this topic even more relevant. I personally think that if a person wants to work in software, not only do you need to continue learning, you have to know more and more of your relevant tech stack as well as the complete life cycle of the applications you work on (aka ‘Full Stack Developer’).
Ok, back to the application. In this post, I will create the Web Application Programmable Interface (API) that will call the data layer created in the last post.
From a design perspective, I am going to lay out the API methods with how I think they will be used. From the Keep It Simple Stupid (KISS) and You Aren’t Going To Need It (YAGNI) design philosophies that I have grown to love and cherish, how a system will be used is one of the best ways to architect things. Yes, keeping an eye on the future and not putting yourself into a corner are important, but those are considerations (in my opinion) that go along with use.
So, how will this be used? I am thinking two pages in a master/slave paradigm (or perhaps a single page app with two panels?). Either way, there will be two ‘displayable’ units. I am thinking I will need these methods:
- GET – Retrieve list of locations for the summary view.
- GET w/id – Retrieve a specific location with its corresponding details record for the details view.
- POST – Create a new location with its corresponding details record (called from the details view).
- PUT – Update a location with its corresponding details record (called from the details view).
- DELETE – Delete a specific location and its corresponding details record (called from the summary view).
The controller class looks like this:
Couple of things:
- To make a post body return values (at least in .NET), you must decorate the models with ‘Serialiable’ and ‘DataContract’ and each property with ‘DataMember’.
- In a real project (i.e. other than exploring and/or for demonstration), I would do a complete set of unit and integration tests. I will not being doing that in this series.
- I am creating this project in .NET Core 2. Moving forward, all projects should be down in .NET Core (I think)
- Configuring the database connection is a little different. At first, I was looking for the web.config. Then, I realized everything has been moved to appsettings.json. Then, another surprise when I realized the connection string was already set in the generated class ‘MyAwesomeDatabaseContext.cs’. For now, I am going to leave this as is. But, if this were a real project, the configuration would have to be in the appsettings.json file (I think).
- Again, if this was a real project, I would have injected the database context into the LocationController.cs via the constructor. Here, I am just going to instantiate it there.
Next will be the basic Model View Controller (MVC) client.