Better explanation of service container and lifecycles #26
Conversation
|
|
||
| The `public TodoController(ITodoItemService todoItemService)` line defines a **constructor** for the class. The constructor runs only once when the class is first initialized, and you've now declared that the `TodoController` class will need to be given an `ITodoItemService` to be initialized properly. | ||
| The `public TodoController(ITodoItemService todoItemService)` line defines a **constructor** for the class. The constructor is a special method that is called when you want to create a new copy of the class (the `TodoController`, in this case). By adding an `ITodoItemService` parameter to the constructor, you've declared that in order to create the `TodoController`, you'll need to supply an object that matches the `ITodoItemService` interface. |
There was a problem hiding this comment.
would change "create a new copy of the class" to "create a new instance of the class" to stick to proper OOP terms
There was a problem hiding this comment.
I agree with @Welkie, though I feel like this still lacks a little clarity. Where do we define instance? Does a reader understand that a class is instantiated into specific object instances? Essentially, do they understand that an instance is an object?
There was a problem hiding this comment.
@davidshq I think this is where it becomes really important to define the scope of this book. It works well because it's condensed. We might want to avoid it spending too much time on basics (what is OOP? etc) or getting into the depths of ASP.NET Core.
While I think the best person to decide this direction is, @nbarbettini, my opinion is that readers should be expected to have a basic understanding of programming including object-oriented programming.
There was a problem hiding this comment.
I agree with @Welkie. This book must assume a basic level of understanding of OOP concepts. There are plenty of existing resources that cover the basics of OOP. Maybe expressing this assumption in a foreword or introduction, with links to some good reading resources would be sufficient?
There was a problem hiding this comment.
Awesome discussion, thanks. Playing devil's advocate: there are plenty of younger coders who maybe have experience with Node or React but don't know much about OOP yet. I shied away from using many OOP terms because I didn't want to get too jargony and potentially lose those folks. Do you agree/disagree? Interested in y'alls thoughts.
This is a pretty minor case, though - saying "new instance of the class" isn't likely to be a problem. 😄
There was a problem hiding this comment.
Wow that's actually a good point. I grew up with OOP, but lately I do indeed spend most of my time in the JS world. In fact, my school just transitioned to a new curriculum that ditches PHP and ASP.NET as an intro to web development and uses Node and Angular instead.
In that case, I think it would be a good idea have a section with an intro to OOP concepts, maybe with a disclaimer that it's an optional section that can be skipped if readers are already familiar with OOP.
It may also do double duty as a nice intro to C# language features too, which means there would be less need for comments about C# features in the rest of the book (for example, talking about the constructor, or a generic type), making the rest of the book flow nicer. In this case, the section would be best pitched as an "intro to OOP concepts in C#" so that both those new to OOP and new to C# would know to read it first before continuing.
I think in the end, whether or not this section is added depends on the target audience:
- Those with programming experience who are new to web development and/or ASP.NET Core
or - Those with little programming experience who want to start by learning web development, starting with ASP.NET Core
There was a problem hiding this comment.
my school just transitioned to a new curriculum that ditches PHP and ASP.NET as an intro to web development and uses Node and Angular instead
I have a feeling we'll see more and more of this! (Not in a bad way)
I think it would be a good idea have a section with an intro to OOP concepts, maybe with a disclaimer that it's an optional section that can be skipped if readers are already familiar with OOP
I like this idea, although not quite sure where to stick it yet. Definitely early on.
Those with programming experience who are new to web development and/or ASP.NET Core
That's the target audience in my mind, although I'm defining "with programming experience" loosely, so junior folks aren't excluded.
|
|
||
| > Dealing with `Tasks` in .NET is much easier than JavaScript callbacks (and the "callback hell" that sometimes results), because of the magic of the `await` keyword. `await` lets your code pause on an async operation, and then pick up where it left off when the underlying database or network request finishes. In the meantime, your application isn't stuck or blocked, because it can process other requests as needed. Don't worry if this doesn't make sense right away, just keep following along! | ||
| > Dealing with `Tasks` in .NET is much easier than JavaScript callbacks (and the "callback hell" that sometimes results), because of the magic of the `await` keyword. `await` lets your code pause on an asynchronous operation, and then pick up where it left off when the underlying database or network request finishes. In the meantime, your application isn't stuck or blocked, because it can process other requests as needed. This pattern is simple but takes a little getting used to, so don't worry if this doesn't make sense right away. Just keep following along! |
There was a problem hiding this comment.
Not all readers will have experience with JavaScript, so this might be better positioned with "If you're familiar with handling asynchronous code with callbacks, like in older JavaScript..." instead of right now where it implies the reader should know about callbacks as if it were basic knowledge.
| Add a new line anywhere inside the `ConfigureServices` method that tells ASP.NET Core to use the `FakeTodoItemService` for the `ITodoItemService` interface: | ||
| The job of the `ConfigureServices` method is adding things to the **service container**, or the collection of services that ASP.NET Core knows about. The `services.AddMvc` line adds the services that the internal ASP.NET Core systems need (as an experiment, try commenting out this line). Any other services you want to use in your application must be added to the service container here in `ConfigureServices`. | ||
|
|
||
| Add a new line anywhere inside the method that tells ASP.NET Core to use the `FakeTodoItemService` whenever the `ITodoItemService` interface is requested: |
There was a problem hiding this comment.
would change "a new line" to "the following line", new line sounds like the character. xD
nbarbettini
force-pushed
the
explain-service-container
branch
from
3384852
to
34fa1ce
Compare
|
Thanks for the proofreading and feedback y'all. I incorporated the feedback and tweaked the language a bit. I'll leave this PR open for a few days in case anyone wants to take another look. |
No description provided.