Devlog #2 MyLife.NET - Let's get to the Core!

After we clarified the why, how, and what in the first article of this series, the second part deals with literally the core of it all: the subproject MyLife.Core, which contains all the necessary and shared models, functions, and services.

Let's be realistic: it's not rocket science

As a nerd, software engineer, and maker, one tends to plan things bigger and more complex than initially or even ultimately necessary. I'm certainly no exception here. For this reason, it took me a while to realize that what I have in mind with MyLife.NET (GitHub) can be implemented with the simplest tools of .NET and Visual Studio.

For me, it's important to have a starting point that is clear and delivers results quickly, as leisure time has become a precious commodity for all of us. That's why proven libraries are used not only in MyLife.Core, but generally in the solution - quite different from my usual mindset of writing everything myself to learn as much as possible. This time, I really want to focus on the result and not so much on the journey - let's see if I can make it happen.

Classic models with JSON annotations

Since MyLife is my first serious project in the .NET ecosystem in a long time, I initially rely on proven techniques. The data structure of the domain transfer objects (DTO), i.e., the objects that ultimately contain the data structure, is based on C# classes with annotations from the well-known and widely used NewtonSoft.Json library.

For now, there is no validation at this level. For a simple start, the JsonProperty annotation is the only use of the library that affects the resulting JSON file. In the future, more functions from this dependency may or may not be used - either way, it's nice to know that if needed, it is a tested and stable feature. Cheers to the mature .NET ecosystem, where in my opinion, there is more stability in the world of dependencies than in other languages and systems.

Alternative: record structs

In modern C#, there is the feature of "record classes" (Microsoft Learn) or record structs, which are set up very similarly to Kotlin data classes and greatly reduce a lot of boilerplate code from traditional class-based writing styles.

At the time I started with MyLife.Core, I lacked a deeper understanding of these language features, and with regard to editable models in the future, I initially dropped the use of records.

Sample data is gold

With the SampleGenerator.cs, I hit several birds with one stone. On the one hand, it describes _my_ life, so I don't have to build the structure twice, and on the other hand, I can use it as a basis for functionality as well as entire upcoming subprojects like Blazor and Co to populate and showcase data from the beginning - as well as, as the name suggests, use it as mock data during the creation of interfaces.

Smart people would also use such fixed data sets to validate created test runs. Nevertheless, I try to build MyLife.NET in a way that with the simplest change of parameters, one can let their own life flow into the lives of other people.

The console as a life generator

In the same context as the models, the generator, which is based on the models of the choir, is also based on a simple console application with scattered Console.Write and Console.Read calls.

Of course, you could also build a user interface here, or even do everything on the web - but why? For a simple conversion of the data set into a JSON file on the computer's disk, you don't have to travel around the world just to shop at the nearby supermarket.

Why not in MyLife.Core?

This user interface for exporting life is not platform-independent, and creating a JSON structure as a file is not a use case that is universally needed.

For me as a beginner, or for someone who likes to download and start open source code, it's always good to have a main project - i.e., without a suffix in the name - that I can always start and that shows me a certain functionality of the application. That's why the console application is not in a MyLife.Exporter, but, as mentioned, at the top level in the MyLife project.

What's next?

Now that we can generate a JSON file thanks to MyLife.Core and save it thanks to the exporter, the next step will be towards Blazor Web Assembly to present the data in a more comprehensible way for us humans. Since I have zero knowledge of Blazor as well as the whole story around web development, it probably won't be a perfect solution, but it picks up on the first section again. It doesn't have to be perfect, for the start, I want to show you that it's possible and continuously improve it over the coming weekends.

If you want to participate because you want to show me how something is done right or easier, or if you want to contribute to a still manageable .NET solution for the first time, you are welcome to visit GitHub, fork the repository, open issues with problems or suggestions, or simply browse. Nachdem wir im ersten Artikel dieser Serie das wieso, weshalb und warum geklärt haben beschäftigt sich der zweite Teil mit buchstäblich dem Kern des Ganzen: Mit dem Teilprojekt MyLife.Core, welches alle benötigten und geteilten Models, Funktionen und Services enthält.