In this piece, I share why and how I created a NuGet Package to optimize some repetitive tasks thus affording me some much needed family time.
As a dad, one of my creative approaches to work lately involves exploring ways to save time on recurrent tasks. Way I see it, time saved on these mundane tasks is Daddy time gained to spend with my family. That’s motivating enough!
Background
Most of my backend related projects using Asp.Net involve the use of Entity Framework and support CRUD operations which is typical of client-server applications. In other words, these projects require Creating, Reading, Updating and Deleting data to and from a database. To that end, my projects are usually structured using a Repository pattern for ease of unit testing and in compliance with the Separation of concerns principle. Hence, I usually maintain separate Asp.Net Class Library Projects for my Business logic, Data and Services.
With that, my services layer for CRUD projects are typically interfaces and implementing classes for the reading, creating, updating, deleting and archiving items to and from my data source. This is a repeatable pattern, hence the following
Wouldn’t it be great to simply create a generic class library for CRUD operations? Even more, wouldn’t it be great if I made that class library globally available for .Net developers?
Enter NuGet Packages
Simply put, a NuGet is a package manager designed to enable developers share reusable code. In other words, it eliminates the need to reinvent the wheels in programming projects.
One of the pros of Asp.Net Core is its support for reusable components. That way, projects which start out as bare bones can grow to include different features via external packages. In my experience, it’s rare developing robust .Net software without the use of NuGet packages. Popular NuGet Packages include Newtonsoft.json which provides functionalities for serializing and deserializing JSON, CsvHelper for processing csv files and FluentEmail for sending emails.
In a nutshell, a NuGet Package is no more than a class library project. It’s also quite easy to develop one using Visual Studio (you could also use Visual Studio Code).
Solution
I decided to create a NuGet package that I could simply add to subsequent CRUD projects without having to rewrite interfaces and classes for my services layer. The result is here BabaFunke.DataAccess NuGet. There is also a demo in Part II showing how the NuGet package is used in a real-world project.
How?
Here’s a how I went about the process of creating the BabaFunke.DataAccess NuGet package in Visual Studio.
- Open Visual Studio, select ‘Create a new project’ and chose the ‘Class Library (.Net Core)’ template. A class library is simply a collection of program code, data, and resources that can be can used by other programs and are easily implemented into other Visual Studio projects. .Net Core is preferred over .Net Framework given its cross-platform support. Consider the latter for legacy projects.
- Name your project. Mine is BabaFunke.DataAccess and press ‘Create’
- There are 3 main files for this project. The first is an interface called IPrimaryKey.cs. This has a single property Id which will refer to the Primary Key property of its implementing class. I added this as a constraint to ensure the implementing entity has a primary key property.
- The second is an interface called IRepository.cs. This uses a generic property T which is replaced by the entity of the implementing project. Additionally, it ensures that any implementing class must also inherit from the IPrimaryKey interface defined above. This is a constraint that ensures that your model is structured in a manner that has a primary key definition. Each method is asynchronous and caters to the different CRUD operation. I have included an ArchiveItem method as an alternative to delete. A product could be archived by hiding its visibility using a boolean property.
- The last file is a class which implements the interfaces. It’s an Abstract class. I have also made the methods virtual since they should be overwritten.
Build
To publish your Nuget Package in VisualStudio, first, right-click the Solutions explorer and select Properties. Fill in the details under Packages Tab. Make sure you check the box ‘Generate NuGet package on build’ then Save the changes.
Next, build your project. That’s it! Your NuGet package is then generated and saved to your project’s bin/debug folder. Note the location of this as you’ll need it when publishing your NuGet package for distribution.
Publishing
This depends on if you want to make it available publicly or privately. For public usage, create an account on Nuget.org. While there, you should also acquire an API key for signing.
In Visual Studio, open the Package Manager Console then run the following command
dotnet nuget push C:/Users/**/bin/Debug/BabaFunke.DataAccess.1.0.1.nupkg --api-key [YOUR_API_KEY] --source https://api.nuget.org/v3/index.json
Remember to replace file location C:/Users/**/bin/Debug/BabaFunke.DataAccess.1.0.1.nupkg and API Key with yours
That’s it! Wait for some hours for nuget.org to list your package so that it’s publicly available for use by everyone.
Conclusion
How might this be useful to you? As a .Net developer, you may have certain repetitive features that cut across your projects. If so, turn them into class libraries and package into a private or public NuGet package. On another note, if you’re familiar with the repository pattern then my NuGet package can save you the need for writing multiple interfaces to implement CRUD operations. In Part II, I walk you through a demo using my NuGet package. if you’d like a helping hand or have related feedback, feel free to contact me.
References