.NET Core - First Impressions
Here at GT4 Design + Web we have primarily focused our website development on the ASP.NET 4.5+ platform and building most of our websites using the Umbraco content management system. This has served us very well in recent years and continues to do so.
However, being the curious developers that we are, we have also been keeping a close eye on the progression of .NET Core over the last year or so.
Although, we may not be able to fully utilise .NET Core in our day-to-day development of such projects like our Umbraco powered websites (for now at least), we have been able to start developing .NET Core applications for some of our internal projects.
Having now worked on a few proof of concepts and currently working on a few internal projects using .NET Core, I just wanted to share my thoughts, first impressions and the aspects of .NET Core that we really like.
It’s Cross Platform
The .NET Framework, as we know, has only ever been able to run on the Windows platform and required a Windows based PC with Visual Studio to develop applications. With .NET Core this is no longer the case. .NET Core applications can be developed on multiple platforms such as Windows, Mac OSX and various Linux distributions.
Personally, this is quite a big deal for myself as I currently use a MacBook Pro with a Parallels Virtual Machine to run Windows.
So now, when it comes to developing .NET Core applications, I won’t need to use my Windows Virtual Machine as I’ll be able to develop applications natively on the Mac side. On the Mac side my IDE of choice has been Visual Studio Code. This is available for Windows and Linux as well. Visual Studio for Mac (Preview) is also available, but I have not yet had a chance to review this properly.
It’s Open Source
Unlike previous .NET Frameworks, .NET Core is open source. This means that it’s free and we have access to the full source code.
What I like about this is that that we can fork our own version, add new features and fix any issues depending on our needs.
To be perfectly honest, I don’t actually see myself doing this all too often, but it’s good to have the ability to be able do this, should the need ever arise.
Entity Framework Core
Entity Framework is also available within .NET Core, which installed as a NuGet Package. The .NET Core version is called Entity framework Core, which is a lightweight and cross platform version of Entity Framework.
Entity Framework Core is not as fully featured as the main Entity Framework, but there is enough in there for use with most types of applications.
The setup of Entity Framework is slightly different in .NET Core, in that the configuration is normally handled within the Startup.cs file, as is with most other services in .NET Core.
Services are registered with dependency injection at application startup. As for the components that require the use of these services (i.e. MVC controllers), the services are provided to such components through constructor parameters.
Personally, I prefer this approach as I believe this encourages good design and best practice and isn’t actually too far from what we are currently doing in our applications at the moment.
Code First or Database First?
From what I have seen so far, Entity Framework Core seems to have more of a focus on the Code First side of things. Which is good and in most of my proof-of-concept applications this is the approach I have taken. It works well and you can get a CRUD application up an running in no time at all.
However, recently I have been tasked with developing a .NET Core application that is using an existing database that I have absolutely no control over. As there is not really any support for the Database First approach in Entity Framework Core in the same way as it has been previously using an EDMX file for example. Instead, in Entity Framework Core we have to "Reverse Engineer” the database structure to generate the relevant Entity Framework models.
The reverse engineering requires the following NuGet Packages to be installed:
- Microsoft.EntityFrameworkCore.SqlServer
- Microsoft.EntityFrameworkCore.Tools
- Microsoft.EntityFrameworkCore.SqlServer.Design
This then needs to be followed by running the following command in the Package Manager console, which should generate the relevant Entity Framework models and DbContext:
Scaffold-DbContext "Server=(local)\SQLExpress;Database=MyDb;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer -OutputDir Models
Having previously been familiar with using the EDMX approach for working with an existing database, this approach seemed quite odd and unnecessary at first. However, having worked through this approach, I can definitely see why this approach was taken. From my point of view, using the Scaffold-DbContext to generate the Entity Framework models does make sense as the models it generates are pretty much consistent with the models that you would create using the Code First approach.
The only drawback to the Database First approach is that you will need to run the Scaffold-DbContext command each time you make changes to the database. This is probably fine for most scenarios, but the project I am currently working on has multiple databases that changes may be made to regularly. So, this would require me to run the Scaffold-DbContext command for each database each time changes are made and depending on the size/structure of the databases, this can take a bit of time to generate meaning that running the Scaffold-DbContext command each time would probably be very time consuming.
At the time of writing this, I am currently looking into utilising Gulp.js in order to automate the running of the Scaffold-DbContext command for each database. This will be documented this in a future blog post.
Conclusion
So far, we really like what we are seeing in .NET Core. Yes, there are a few caveats, but nothing that can’t be worked on and I'm sure the framework will only improve and get better as time progresses.
We will definitely be looking to utilise the .NET Core in many of our projects where we can!
