In lesson 1.4.6 you got to know the five SOLID principles in the small, and in the end the Kladde’s core knew neither the console nor files. Until now, that was a precaution. Now it gets serious: from module 2.1 on, the Kladde gets a second interface, a web application, and it uses the same core as the console. What sits in the core and fits only the console now stands out.
In this lesson you follow up on that question. You refactor a given service that has three typical flaws, and you secure every step with tests. After that you check your own Kladde and have the compiler make sure the core stays clean.
What changes when the Kladde moves to the web?
A console and a web application differ in more than how they present things. Go through the differences once:
| In the console | On the web | What the core therefore needs |
|---|---|---|
| one person, one program that they start | many people at once in one program that runs on a server | no shared state in static fields; what one person changes mustn’t get in anyone else’s way |
confirmations with Console.ReadLine, such as “really delete? (y/n)” |
a confirmation page or a form | confirmations are operation and stay at the edge; the core offers only the deletion itself |
output with Console.WriteLine |
HTML for people, JSON for programs | The core delivers data: records, lists, a Result with error codes, no finished sentences |
| texts in English | English and German (module 2.5) | error codes in the core, texts in the interface, like ErrorTexts since lesson 1.6.2 |
| the clock and time zone of your own machine | a server, often in UTC, and visitors in other time zones | a clock (TimeProvider) and the office’s time zone from outside |
| a file in the user folder | a database (module 2.4) | a contract like IKladdeStore that the core defines and somebody else fulfills |
Program.cs puts the parts together by hand |
ASP.NET Core puts them together with dependency injection (lesson 2.3.3) | dependencies in the constructor, nothing else |
| an error ends with a message and an exit code | an error becomes a status code with a description (lesson 2.3.7) | expected errors as a Result, exceptions only for the unexpected |
The row with the clock deserves a second look. On a machine set to Berlin time, DateTime.Now returns the time in Berlin. In the cloud,
servers almost always run in UTC. At 0:30 in Berlin it’s 23:30 the day before there. A core that asks DateTime.Now then shows
yesterday’s appointments, and every test on your machine is green anyway. Errors like that are found only once they stand out.