Building the application in forward order is better about little-aspnetcore-book

[nbarbettini]

This was a style choice I made intentionally. I think it's easiest to learn when:

• You only learn a little bit of new stuff at a time
• You repeatedly reinforce what you already know

This pattern is used throughout the book. I think of it as "taking a step into the unknown, and then letting your understanding catch up".

I tried to deliberately make the "new thing" you learn the obvious next step, even when it isn't necessarily the order you'd do things as an expert. For example, you're right that an expert would add the Constants class early on, because they already know they'll need it. As a beginner reading the book, you don't already know you'll need it. I show the simplest, obvious thing first (hardcoding the string "Administrator"). Then, gently introduce the idea of refactoring it, but only after that string had been used in more than one place.

It does mean that you can't compile the code after every single step. The very next step should always be adding the file you are missing, though.

I'm curious to hear feedback from others on this style. I think it's helpful for beginners, but that might just be me.

[mattwelke]

I liked that style as I read through it. However, I'm not a beginner, so I was okay with not being able to compile after each step. At this point in my career, I prefer this style of filling it in one step at a time as opposed to writing something that will compile, and then having to replace most of what you just wrote for the next step (which must also compile).

[sadqiang]

@Welkie : I am not talking about replacing the previous code with new one to proceed to the next steps. Only for illustration purpose, for example, if we want to create a new class CCC that needs other classes BBB and AAA, then AAA and BBB should be created first. It is what I meant as forward order like building a house; we start building from the ground level to the higher level.

[GarethOates]

I must say I prefer the approach taken in the book. Introduce the simplest new piece of information first and then gradually build up the complexity. Yes, it hurt a little bit when typing a "magic string" into the attribute, but then it was a relief later on to refactor it out into a constants class. I think this is the best approach for beginners and to be honest, how I code most of the time as well. If you take the YAGNI approach, like @nbarbettini said, it's only after you use the string a few times that you think 'hmm, maybe this needs to be in a constants class'. If you only ever end up using it in one place, then you ain't gonna need a constants class.

[mattwelke]

I agree with @GarethOates. The approach where you cause a problem and solve it like with the constants class is great because it can help beginner programmers recognize the situations in the future as they code where they'd want to fix those magic strings with a constant. I know this is a subject where people will disagree, but I definitely liked the style @nbarbettini used to write the book. It's what lead to me finishing it and what drew me to this repo.

[nbarbettini]

Thanks for the feedback everyone! I've made some small changes in version 1.1 (out today) that explain a few things earlier, but overall I've kept this style as I think it works well.