Nancy and Sinatra anyone? :)
Minimal APIs at a glance in .NET 6
91–100 of 114 posts
Re: Minimal APIs at a glance in .NET 6
#92Earlier quoted context omitted.
Controllers still control, believe it or not. I want tests to assert that I return a file type. Theres method on the base controller for doing that. It, too, is protected. So I need to wrap my controller in a test. Need to assert that the response differs based on the content of a header, or a cookie? Need to use test the controller. etc. The basest of assertions I want tested is that the controller returns/uses the…
But there are multiple ways to return a file type. There are also multiple ways to define a route. You can name the method item[] GetItem() or use attributes [HttpGet] item[] Items(). If you do integration testing, you verify what will be returned in the end to the caller over http. For that you don’t need selenium. Just use testserver, it’s just a few lines of c# Code.
Unit testing and integration testing are not mutually exclusive. I use both. I also want the feedback from tests/build of what I am developing to be as immediate as possible. Failing early with a test that takes a second to spool and run with a message like "expected File got Content" or whatever is more valuable than waiting for a much longer test for the same (or more obscure due to depth of stack that will need a debug session) message.
TL;DR: Running an entire webstack to test trivial things is waste.
> Just use testserver, it’s just a few lines of c# Code.
Orthoganol metric is orthoganol.
await Task.Delay(TimeSpan.FromHours(1));
Re: Minimal APIs at a glance in .NET 6
#93Earlier quoted context omitted.
> At least when the controllers are all classes I can unit test them. I was always having great difficulty testing ASP.NET MVC controllers given the use of completely closed off, cyclical dependency, sealed class, properties like HttpContext. Helper libraries made it somewhat easier to set them up but they were always heavy tests as a direct result of the large object graph needed.
In ASP.NET Core the HttpContext is very mockable.
And is very much appreciated.
Re: Minimal APIs at a glance in .NET 6
#94Earlier quoted context omitted.
I'm happy to get rid of the "organized OOP template" which is really just a bloaty mess of unnecessary classes. Given that all the IoC and request binding systems are supported in these minimal APIs I have no reason to believe I'll ever have to write a Controller class in .NET 6 again at the moment. And I won't miss it. The MVC pattern from ASP.NET MVC never did make sense for web requests.
I never considered this as OOP ... they are just names to give some organization. I think the only OOP is the instantiation of the controllers ... which are instantiated per request => pointless ;). So you are right, easy to transfer, but we will see midterm new file/naming based structures showing up when the first teams working with minimal apis with massive amount of apis.
> I think the only OOP is the instantiation of the controllers ... which are instantiated per request => pointless ;).
which has nothing to do with oop. that is IoC and they are (by default) scoped per request (but do not need to be scoped per request, singleton controllers are fine. (AddControllersAsServices)) btw. controllers by default do not get "built" by IoC but the helper "ActivatorUtilities#CreateInstance(IServiceProvider, Object[])" uses it to resolve dependencies of the controller. if you add "AddControllersAsServices" it will use the IoC directly and skip using "ActivatorUtilities#CreateInstance" (and the IServiceProvider of the controller as created with the IServiceScopeFactory) and you can basically overwrite the behavior however you want, by using `IControllerFactory`.
Re: Minimal APIs at a glance in .NET 6
#95Earlier quoted context omitted.
What's so bad about using reflection and attributes in this context?
Attributes have to be at one specific spot (before the method/class declaration). Functions and builders you can compose. You can, for example loop, over something and add multiple routes programmatically. For example if you load the routes from a database, it’s really hard to create attributes. You would need to compile and load assemblies on the fly, or do some reflection black magic.
btw. in .net core you can either use attributes or builders to create your routes or even more stuff. at least since (i think) 3.0.
and if that is not a great fit you can actually build your own routing by creating a middleware (btw. the endpoint routing stuff is just a middleware)
Re: Minimal APIs at a glance in .NET 6
#96Earlier quoted context omitted.
I think the fact that this maintains type safety, IDE integration and other useful traits of modern C# like zero-allocation primitives gives it a leg up over TypeScript/JS in some cases.
This
Funny, that David ends this discussion.
Thanks!
PS: oh no, now I am ending it :)
Re: Minimal APIs at a glance in .NET 6
#97Earlier quoted context omitted.
1. The web server component could be fronting a middle-tier written in C#. There are numerous advantages to doing this in .Net over Node. 2. Performance. 3. Native AOT is coming in 6.0. Meaning, you get a native platform specific app which can run without the framework - like golang. But with GC, so not like C/C++/Rust.
I've been using C# since it was released, and I'm a huge fan. But I can almost guarantee that native AOT doesn't appear with dotnet 6 - they've been promising it for several years, and it's become Microsoft's Duke Nukem Forever,
yeah and the sad thing without NativeAot there won't be the WebAssembly things which we would like. the way it works now is way too lazy for anything real world. (compiling the runtime to wasm and loading dll files...)
Re: Minimal APIs at a glance in .NET 6
#98As someone who isn't familiar with .NET, I wish this post had an example with a JSON request body and response.
You can bind JSON to structs: https://gist.github.com/davidfowl/ff1addd02d239d2d26f4648a06...
Or you can customize how it happens: https://gist.github.com/davidfowl/ff1addd02d239d2d26f4648a06...
As for responses: https://gist.github.com/davidfowl/ff1addd02d239d2d26f4648a06...
Re: Minimal APIs at a glance in .NET 6
#99Earlier quoted context omitted.
It is still some kind of reflection magic. Also most frameworks moved away from attributes and towards builders. For example entity framework or Microsoft.extensions.dependendyinjection.
What's so bad about using reflection and attributes in this context?
1) Startup time: reflection can take a ton of time to run. It only needs to happen once, but especially as more and more web servers move to idle models where cold startup time matter rather than just holding on to a warm service, it's not always as amortized as before.
2) AOT compilation support/size: relying on Reflection APIs means that much more metadata/symbol data has to be preserved during an AOT compilation. This impacts metadata that needs to be passed to the AOT pass and final build size from the AOT. Some web applications are interested in delivering full, streamlined AOT builds rather than typical .NET CLR applications (and JIT compilation).
Re: Minimal APIs at a glance in .NET 6
#100I don't know what to think about it. Half-baked idea: use free functions only in one file in project is meh..
Modern Kotlin, Scala, F# can and use free functions and reduce boilerplates to minimum. C# developers wants attract newbies, juniors, fans of J's, python etc and simultaneously don't disturb old users, fans of c#/java and enterprise development.
"It's only for quick scripts, prototyping, for teaching". Choose a side, don't pretend that you are modern and cool.
Modern c# is fine, but some features are only sugar, and yet i still waiting for proper sum types with exhausting pattern matching. Slow progressing java have this in 17 version..