ASP.Net Core 2 with Postgresql on Linux Part 5: Data Model Layer, Etc.

In In Part I, I discussed the rationale for porting a ASP.Net Core 2 app to my Linux system replacing SQL Server with Postgresql and place it on Heroku. 

With Part II, we transferred the SQL Server data to Postgres.

In Part III, I create the ASP.Net MVC Core 2.x app, from which we will proceed, and get Entity Framework Core installed.

Then in Part IV, I look at the configuration differences between the ASP.Net MVC app that uses SQL Server and the new app, in preparation of porting the old app to use Postgresql.

Here in Part V, we will start comparing the differences in both the projects' structures and porting the existing project code, starting with the data model layer, to the new project.

Since the next step is to look at the existing Windows ASP.Net MVC app using SQL Server and to move it to a Linux system with Postgresql, I thought it best to first look at what the overall differences are in the two projects.

So, using Beyond Compare, as mentioned in the previous post, to look at the differences in the folder structure, here are my initial observations.

First, note that there is a bower package component folder that is not present in the new app. Within the folder bower_components folder you see jquery.countdown. As per their site, they state to use the following to install:

 $ bower install jquery.countdown  

While their github page offers other installation methods via npm, et al, bower is still solid. However, even bower is encouraging a move to yarn...yet bower is still being maintained. 

Looking at further differences, there is a Data folder with Entity Framework Core classes as well as classes that implement them.

Then, I copied the Entity Framework Core classes as well as the implementation classes to a Data folder in myApp. 

Of course, this will not be useful until the controller and view objects are ported as well. Meanwhile, I will get unit tests for the the data model layer...more on this later.

So, given the fact that, as found above, that bower is encouraging a move to yarn, it seems prudent to make that move for this app now. Per Yarn's site, here is what I did:

 $ curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -  
 $ echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list  
 $ sudo apt-get update && sudo apt-get install yarn  

Next, I attempted to install jquery.countdown via yarn with:

 $ yarn install jquery.countdown  

The result was the following:

 yarn install v1.5.1  
 info No lockfile found.  
 error An unexpected error occurred: "`install` has been replaced with `add` to add new dependencies. Run \"yarn add jquery.countdown\" instead.".  
 info If you think this is a bug, please open a bug report with the information provided in "/home/mark/Code/dotnetcore/myApp/yarn-error.log".  
 info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.  

So, per the above instructions:

We will test the install jquery.countdown later, meanwhile let's try to build the myApp project.

As expected, there are things missing and the build fails.

Given that we have just ported classes that have a different name space as well as references to objects that are not in the project, we have a great deal of red text above. Now to make the corrections.

First, I replaced the old reference to the m2prayerVS2017NetCore.Models name space with myApp.Models in each of the migrated Entity Framework Core classes. Also, the Migrations folder were from the previous project and not needed here. 

After commenting the Entity Framework Core code that was calling into missing model files, I issued the following command to get the model objects scaffolded from the Postgres database:

 $ dotnet ef dbcontext scaffold "Host=localhost;Database=postgres;Username=youUserName;Password=yourPassword" Npgsql.EntityFrameworkCore.PostgreSQL -o Models  

Then, I uncommented the Entity Framework Core code and corrected for the lower-case use of table names that are conventional with Postgresql. For example, while SQL Server will have a table named AspNetUsers, Postgres' naming convention entitles it aspnetusers.

Yet, when attempting to build, I found that I was missing the ApplicationUser class from the Models namespace. 

After copying it from the old ASP.Net app and updating the namespace name, the project would then build.

Oh my, I just realized that we do not have this project in any kind of source control! Let's take care of that right now. Essentially, I followed the steps here.

Given that the Entity Framework Core data classes have been moved to the myApp application and the model objects scaffolded, creating unit tests utilizing them is the next step. Therefore, in Part VI we will look at setting up unit testing in order to test both the new and future code.