Earlier quoted context omitted.
"if you load the routes from a database" Serious question (honestly not being snarky) - why would you want to do that?
I don’t know, nobody needs more the 640k of RAM, right? Maybe you have multiple modules, and depending on the configuration the routing changes. Or feature flags, that enable a breaking api change. Or a stupid customer that pays you a million dollar for custom routes. But what benefit do the attributes bring? You need to learn them by heart, on builders Intellisense can help you.
Minimal APIs at a glance in .NET 6
61–70 of 114 posts
Re: Minimal APIs at a glance in .NET 6
#62Earlier quoted context omitted.
I don’t know, nobody needs more the 640k of RAM, right? Maybe you have multiple modules, and depending on the configuration the routing changes. Or feature flags, that enable a breaking api change. Or a stupid customer that pays you a million dollar for custom routes. But what benefit do the attributes bring? You need to learn them by heart, on builders Intellisense can help you.
Well yes - if you need some kind of dynamically configurable routing then attributes aren't a good fit. I like the fact they are there right next to the relevant method...
If you - for example - write one controller you want to use with multiple frameworks (ASP.NET Core or Nancy), you need one controller per framework, just for the attributes.
I always found them more annoying then helpful. Most people seem to see it that way. Most frameworks are moving away from attributes for a good reason.
Re: Minimal APIs at a glance in .NET 6
#63Earlier quoted context omitted.
But why? generally you don't test controllers directly. You test "service"/"handler" classes that handle those requests. If you want to test controllers, then you write E2E tests that send HTTP requests Here's some example of how it might look like https://docs.microsoft.com/en-us/aspnet/core/test/integratio...
If there's any critical behavior you're reliant on the controller (and, in frameworks like this, its attribute-driven configuration) to provide for you - throwing exceptions for bad requests, authentication or authorization, returning particular cache headers for particular response cases... I'd recommend looking for some way to write tests that, in isolation, go some way to let you assert those behaviors. Don't both…
This way you can test those fancy things, but I agree it's kinda "hard" to get it working for the first time
Re: Minimal APIs at a glance in .NET 6
#64Earlier 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.
But why? generally you don't test controllers directly. You test "service"/"handler" classes that handle those requests. If you want to test controllers, then you write E2E tests that send HTTP requests Here's some example of how it might look like https://docs.microsoft.com/en-us/aspnet/core/test/integratio...
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 right view. That _should_ be trivial but no. Instead I must rely on a super heavy integration test, or worse, a selenium or other test that requires a user-agent and actual webserver, when all I want to is to assert that "View X" is returned for "Scenario Y"
Re: Minimal APIs at a glance in .NET 6
#65Translation for non-web-people: how to write a minimal web service in dotNET. I probably missed when the acronym "API" was hijacked by the web people to describe a custom web service protocol.
Re: Minimal APIs at a glance in .NET 6
#66Earlier quoted context omitted.
If there's any critical behavior you're reliant on the controller (and, in frameworks like this, its attribute-driven configuration) to provide for you - throwing exceptions for bad requests, authentication or authorization, returning particular cache headers for particular response cases... I'd recommend looking for some way to write tests that, in isolation, go some way to let you assert those behaviors. Don't both…
For Selenium tests I've been setting up an actual instance of application in test with different Startup (e.g sqlite instead of real database) and running at different port This way you can test those fancy things, but I agree it's kinda "hard" to get it working for the first time
Re: Minimal APIs at a glance in .NET 6
#67Re: Minimal APIs at a glance in .NET 6
#68I like giraffe better. https://github.com/giraffe-fsharp/Giraffe
Suave is a cleaner API in my view but Giraffe has better performance on the edges.
Re: Minimal APIs at a glance in .NET 6
#69 app.MapGet("/todos/{id:int}", [Authorize("AdminsOnly")] (int id) => "This endpoint is for admins only");
Attributes make things cleaner with everything having its own line. Also you lose the ability to group a bunch of methods in 1 controller together under the same authentication policy.Re: Minimal APIs at a glance in .NET 6
#70Earlier quoted context omitted.
You still get C#/.NET, with it's superior performance and type safety, but just without all the OOP bloat.
Wait, you think this is not OOP? var app = WebApplication.Create(args); app.MapGet("/", () => "Hello World"); app.Run(); You're creating an object and calling methods on it..