Diving into a new Framework. From Ruby on Rails to ASP .Net — C#
In my journey applying for a job, I always see a lot of jobs for junior developers where the require for proficiency in C# and related frameworks, such as ASP .Net, ASP .Net Core and Entity Framework. C# is not one of those languages I had during my bootcamp, and it seemed really different from all that I knew, so never really applied for those jobs.
In one of these process, one company gave me an assessment, a mini project to do with just one requirement: the backend should be built using C#, .Net Core and Entity Framework. Before I move one, I would like to ask you:
Is it crazy they asked to build a full stack application as part of a process to hire a graduate developer?
How about forcing the backend in a technology I had never written before?
Lastly, just one week deadline?
Please, I would love to know your thoughts about it.
Well, since C# is also a OOP language and I don’t really give up on challenges, I decided to it and I built a small application connecting React JS in the frontend and .Net Core in C# for the backend.
In this series of posts, I am going to show what I built, what I learned and my opinion about this technology.
The application consists in having a portal where the user can upload a CSV file with a list of orders where each order has its details, such as instrument, price, volume, and trade type:
So, following these requirements, we just have two models, Client and Order.
.Net Core is a MVC (Mode, View, Controller) framework, and works in a very similar way Ruby on Rails works, so, when you create a new project with .Net Core and tell you are creating an API project, .Net will do the heavy lifting, giving us a couple of boilerplates for our project.
Note: .Net Core / C# is very used in Visual Studio, but we can also use Visual Studio Code (my favorite) for that, we just need to install the C# extension in VS Code and download dotnet:
https://dotnet.microsoft.com/download
First, we create our models:
Wow, it’s shocking and very different, right? Don’t worry, even though I agree this is the first impact, when you think what is going on it’s actually easy to understand:
Using key word is how we import things in C#, so for this class, we are importing System.Collections.Generic.
Namespace is similar to Rails, we are just saying that this class is a model that belongs to a OrderProejct, which is our API.
Then we have a class Client, that is a public class (the whole project has access to it) and it inherits from the Entity class.
Inside of this class, we have our attributes, all accessible to the whole project (public):
A string for Name, Username and Password. Get and Set are, well, getter and setter method for those attributes.
The last field is List<Order>, which means the Client has many orders.
Similarly, the Order model:
Now, with our models created, we need to connect our database and tell the framework what we are using.
Inside of the project, I created a folder called Data with a OrderProjectDbContext.cs file:
The class:
Here we have this class, that inherits from DbContext, this is a unity of Entity Framework, our ORM (Object Relational Mapping), that represents a section of our database, co relating it, it’s our Active Record in Rails.
We then say that we are using our options to config the database (we will see it soon) and that inside of our database, we need two tables, Clients and Orders.
Our options for the configuration live in the startup.cs file (created by the .Net framework):
Here, we are kindly asking to the framework for a service. We want the framework to do the service to AddDBContext (add our db in the Entity Framework context) connecting our OrderProjectDbContext class.
In the next episode, I’ll explain how to create the relationships between our models and how to create and run the migrations. Later on, we will go to the controllers and actions for our API endpoints.
See you next week!
