41–50 of 114 posts
Earlier 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..
There is not a big difference between an FP module and an OOP static or single instance class.
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.
More importantly, if the default is to depend heavily on conventions, MS should have had a big glaring button / warning / notification in the Introduction page, which summarizes all the conventions used. Would have saved many beginners a lot of time. I am an experienced programmer and was very frustrated having to search for all the conventions used in the framework.
Earlier quoted context omitted.
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..
This is more functional. C# is an multi paradigm language. There is not a big difference between an FP module and an OOP static or single instance class.
I like giraffe better. https://github.com/giraffe-fsharp/Giraffe
It never takes long when throwing together toy examples with these kinds of APIs to introduce a security risk: var uploads = Path.Combine(uploadsPath, file.FileName); Where file.FileName appears to be drawn from the content-disposition header of the request. MS’s own asp.net docs on file uploads say: “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…
> 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.
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)?"
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 is part of a larger push to make ASP.NET Core and .NET easier for beginners. The difference between node.js + express vs. ASP.NET Core was a lot of boilerplate to return the first Hello World. Overcoming that churn is a huge problem for .NET adoption. Do not take three-line-minimal APIs as the end product for robust, safe and reliable endpoints. We all know better than trusting 3-line-presentations. As a seasone…
It doesn't do big enterprise devs much good if we have a lot of cool new features if there's no path towards using them in our 20 year old legacy applications that keep the business running.
It never takes long when throwing together toy examples with these kinds of APIs to introduce a security risk: var uploads = Path.Combine(uploadsPath, file.FileName); Where file.FileName appears to be drawn from the content-disposition header of the request. MS’s own asp.net docs on file uploads say: “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…
So I've literally just jumped into this world, having never touched asp.net or similar before.
I looked into how to test the controller side of things, and came across this[1] post arguing that unit testing controllers weren't as useful as integration testing them.
Integration testing would definitely be useful, and something I will do, but I assume also a lot more time-consuming so perhaps not something we could do on a per-commit basis.
Would highly appreciate views on this topic.
[1]: https://andrewlock.net/should-you-unit-test-controllers-in-a...
Earlier quoted context omitted.
What about attribute based routing - that makes things nice and explicit?
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.