11–20 of 114 posts
So I guess we've had 'JavaScript but like C#', in the form of TypeScript; so I suppose now we get 'C# like JavaScript'? I must admit, I find this amusing. I suppose this raises two questions: "Why use C# like this in place of express or koa on node, which idiomatically similar?", and "Why use C# like this instead of C# like that (the way all other AspNetCore apps do it)?"
So basically this is expressjs for .NET.
Or if I just add my interfaces to the lambda parameters they will automatically resolved?
edit: It supports DI using `[FromServices]` attribute!
https://gist.github.com/davidfowl/ff1addd02d239d2d26f4648a06...
edit: Apparently this was in the article, but I overlooked it..
Is there any example of how this would work with dependency injection? Or it's expected to manually call the service provider inside the lambda? Or if I just add my interfaces to the lambda parameters they will automatically resolved? edit: It supports DI using `[FromServices]` attribute! https://gist.github.com/davidfowl/ff1addd02d239d2d26f4648a06... edit: Apparently this was in the article, but I overlooked it..
So I guess we've had 'JavaScript but like C#', in the form of TypeScript; so I suppose now we get 'C# like JavaScript'? I must admit, I find this amusing. I suppose this raises two questions: "Why use C# like this in place of express or koa on node, which idiomatically similar?", and "Why use C# like this instead of C# like that (the way all other AspNetCore apps do it)?"
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.
The old convention based model for controllers, was really difficult to understand and debug. You never knew what routes exactly were discovered by reflection. It was just too much magic, and too many conventions. I hope this will make it easier. Reminds me of the good old Nancy times.
Translation 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.
The old convention based model for controllers, was really difficult to understand and debug. You never knew what routes exactly were discovered by reflection. It was just too much magic, and too many conventions. I hope this will make it easier. Reminds me of the good old Nancy times.
What about attribute based routing - that makes things nice and explicit?
var uploads = Path.Combine(uploadsPath, file.FileName);
“Use a safe file name determined by the app. Don't use a file name provided by the user or the untrusted file name of the uploaded file.”
I’m always wary of APIs designed to look good in a DevRel evangelist’s presentation, to show how you can do something in ‘just a few lines of code’, when the reality is that actual applications will need to deal with a bunch more concerns anyway and this terse little API is not going to make one jot of difference to the essential complexity you’re trying to express.
Whether you have a node express style server where you’re able to declare all your controller mappings in-line using lambdas, or a spring style router where controllers are in separate classes and methods makes no real difference to the fact you still have to write the controller body, and in any real application it is not going to be handling everything from request body handling to file system operations in one place anyway.
At least when the controllers are all classes I can unit test them.
The old convention based model for controllers, was really difficult to understand and debug. You never knew what routes exactly were discovered by reflection. It was just too much magic, and too many conventions. I hope this will make it easier. Reminds me of the good old Nancy times.
What about attribute based routing - that makes things nice and explicit?
Also most frameworks moved away from attributes and towards builders. For example entity framework or Microsoft.extensions.dependendyinjection.