Thank you very much guys!! It so amazing to hear how the Microsoft professionals talk about the architecture of the framework we daily use. Thanks! Looking forward to more.
Great talk, would it be possible to link David's power point presentation? I feel there were more nuggets on those slides you guys did not get a chance to go thru
Followed up from project Houdini to this vid. Now that .net 7 is in preview. I Hope the .net team would in .net8 introduces source generator to minimal api.
Wow, that source generator looks like it could improve performance by a lot. A naked request takes about 2 ms for nothing on my machine, i'd imagine if there was less reflection the code could even run in sub 1 ms _with_ actionfilters and their comrades. unless they wait for db calls or other equivalent workloads. If that could be then combined with a source-generated Json serialization, the code would literally be blazing fast for simple CRUD REST workloads!
@@davidfowl I will do my best, but bear with me, it's late and I'm typing on my phone. A Startup class quickly becomes a mess of mixed concerns. Configuration, registration of services, routing specs, etc. Additional abstractions can help alleviate this, to some degree, but anything other than testing what has been registered with which lifetime is often very hard - how do you assert that AddMvc or some other deep extension method has been called? Integration tests have been suggested as the answer when this has been discussed, but integration tests without unit tests is not a good experience - I don't want to have to debug an application to figure out what's wrong. To be fair, I'm now reading about IStartupFilter and other bits I've missed that may help us build our way out of the mixed concerns we haven't managed to get away from yet. Original point still stands, though - for anything other than a simple website, a Startup class quickly becomes a maintenance nightmare.
@@positronalpha I think there’s a tendency to over abstract things in object oriented languages like C#. Startup is where coupling is supposed to happen. It’s where you wire up specific implementations of interfaces for the current environment. It’s where you read configuration files and write the logic to make the rest of the application logic clean. Unit testing the startup class itself IMO is of little value, but you can if you want to. Some people like verifying that certain registrations were made but since we use extensions methods (anything else would require coupling ASP.NET Core tighter which is something we don’t see the value in). That said large enterprise customers love to modularize the startup in various ways that I’ve seen but it’s never perfect, just a different set of trade offs.
The Startup class needs to be unit-tested? It's all infrastructure boilerplate code. If something's wrong there, you won't need a unit test to find out.
@@ronaldmackee3401 An example of apparently recommended (since it's a sample from the ASP.NET Core repo) Startup class usage: github.com/dotnet/aspnetcore/blob/master/src/Security/Authentication/samples/SocialSample/Startup.cs I see quite a lot of things that can be made to go wrong in interesting ways, which I would not want to figure out using a debugger.
Great presentation, we need the 2nd part!
we need a sequel
Thank you very much guys!! It so amazing to hear how the Microsoft professionals talk about the architecture of the framework we daily use. Thanks! Looking forward to more.
Damian is a great communicator.
G
Thank you so much! We're looking forward to the link to used presentation. And perhaps any other resources describing ASP.NET Core architecture...
Excellent talk, thanks for sharing. Please schedule a second part :)
Just look at David smile at 10:20 . There is lot to learn from him and aspnetcore team!
Lol yeah he is genius...
Great talk, would it be possible to link David's power point presentation? I feel there were more nuggets on those slides you guys did not get a chance to go thru
I think it's this one: speakerdeck.com/davidfowl/asp-dot-net-core-architecture-overview
There was talk about the PP presentations? Any chance of the demo project too?
Great talk, super interesting 👏
Awesome!
Followed up from project Houdini to this vid.
Now that .net 7 is in preview. I Hope the .net team would in .net8 introduces source generator to minimal api.
Why is the team so small?
Wow, that source generator looks like it could improve performance by a lot.
A naked request takes about 2 ms for nothing on my machine,
i'd imagine if there was less reflection the code could even run in sub 1 ms _with_ actionfilters and their comrades.
unless they wait for db calls or other equivalent workloads.
If that could be then combined with a source-generated Json serialization, the code would literally be blazing fast for simple CRUD REST workloads!
3:33 i did not get it
The Startup class with extension methods concept is horrible to work with for anything but throwaway websites. Zero testability, instant spaghetti.
Can you explain that? Why isn't it testable and what exactly do you need to test?
@@davidfowl I will do my best, but bear with me, it's late and I'm typing on my phone.
A Startup class quickly becomes a mess of mixed concerns. Configuration, registration of services, routing specs, etc. Additional abstractions can help alleviate this, to some degree, but anything other than testing what has been registered with which lifetime is often very hard - how do you assert that AddMvc or some other deep extension method has been called?
Integration tests have been suggested as the answer when this has been discussed, but integration tests without unit tests is not a good experience - I don't want to have to debug an application to figure out what's wrong.
To be fair, I'm now reading about IStartupFilter and other bits I've missed that may help us build our way out of the mixed concerns we haven't managed to get away from yet. Original point still stands, though - for anything other than a simple website, a Startup class quickly becomes a maintenance nightmare.
@@positronalpha I think there’s a tendency to over abstract things in object oriented languages like C#. Startup is where coupling is supposed to happen. It’s where you wire up specific implementations of interfaces for the current environment. It’s where you read configuration files and write the logic to make the rest of the application logic clean.
Unit testing the startup class itself IMO is of little value, but you can if you want to. Some people like verifying that certain registrations were made but since we use extensions methods (anything else would require coupling ASP.NET Core tighter which is something we don’t see the value in).
That said large enterprise customers love to modularize the startup in various ways that I’ve seen but it’s never perfect, just a different set of trade offs.
The Startup class needs to be unit-tested? It's all infrastructure boilerplate code. If something's wrong there, you won't need a unit test to find out.
@@ronaldmackee3401 An example of apparently recommended (since it's a sample from the ASP.NET Core repo) Startup class usage: github.com/dotnet/aspnetcore/blob/master/src/Security/Authentication/samples/SocialSample/Startup.cs
I see quite a lot of things that can be made to go wrong in interesting ways, which I would not want to figure out using a debugger.