101–110 of 114 posts
Earlier quoted context omitted.
Suave is a cleaner API in my view but Giraffe has better performance on the edges.
When I was doing F#, I loved both of these projects. I don't think we should always view ExpressJS/Sinatra (from Ruby) as "the standard", but there's also something to not having to do an hour of work before we can get endpoints serving responses.
Earlier quoted context omitted.
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.
"if you load the routes from a database" Serious question (honestly not being snarky) - why would you want to do that?
I love this, not because of the "it's for beginners" framing, but from a "I want less boilerplate" framing. I look forward to a future .NET that gets less verbose each release, regardless of language chosen.
I am really looking forward to the day when I can use C# for all my scripting needs instead of Bash/Python/PowerShell. We’re getting there.
Earlier quoted context omitted.
I think the word OOP has lost all meaning and just means "crusty old code I hate".
In the OOP way you create controller classes. In the FP way you pass lambdas/functions. So yes, it’s not 100% functional. But probably 80%?
I just feel like the term OOP can't win here. If it's concise people will just claim it's FP.
I 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…
In the workplaces I've been in newer developers typically try then abandon the OO paradigm. They've seen they can get by without it and get decent performance, and there is a learning curve which experienced people have already paid for and typically then take for granted (patterns, DI, class structure, interfaces vs abstract classes, etc etc etc).
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. There is normally not such a big benefit in unit testing them, as controllers should only call some service behind. This service you can test. Controllers are better integration tested, with a mock service behind. So you actually test if your routing and response codes are picked up correctly by the framework. There is TestServer for asp.net core.…
Earlier quoted context omitted.
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
and wasteful. Starting up selenium et al is painfully slow compared to tests that run in <seconds.
Also depends how many pages do you want to test with Selenium - if you want to test e.g 5 pages, then it'll be fast enough I guess.
There are a few tricks/configurations that make Selenium significantly faster - https://stackoverflow.com/a/57720610
A lot of is also on how do you write your "testing infrastructure" - maybe you could reuse engine/browser instance? execute tests parallelly?
There's also alternative to Selenium by Microsoft: https://github.com/microsoft/playwright
AFAIK it's way more reliable than Selenium (false errors)
__________
Overall you can still start application inside tests with different startup, without Selenium and send http requests, so you'll have end-to-end tests done fast.
Earlier quoted context omitted.
> At least when the controllers are all classes I can unit test them. There is normally not such a big benefit in unit testing them, as controllers should only call some service behind. This service you can test. Controllers are better integration tested, with a mock service behind. So you actually test if your routing and response codes are picked up correctly by the framework. There is TestServer for asp.net core.…
If it has a mock service behind it, how is that an integration test?
A controller usually doesn't contain any business logic, it does the HTTP part. So you test serialization, model binding, return codes, etc.
So you use a mock to check, if the framework does the expected model binding. If the values you post via JSON end up in the right properties for the service call.
a typical controller method would look like that:
IActionResult StoreProduct(Product p) {
var success = service.Store(p);
return success
? Ok("Stored")
: BadRequest("Product doesn't contain all necessary fields");
}
It is often easier to do that with a mocked service, but you can also use the real service for that. Often this would hit the database and make those tests much slower and harder to set up.
Earlier quoted context omitted.
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.
Absolutely. I've wasted hours doing things that, if I'd been shown the way Microsoft wanted me to do them, I'd solve in 10 minutes, but instead I need to spend a ton of time trying to figure out why the new variable on my model isn't binding correctly because I didn't realize they need to be properties.
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)?"
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.
Not only you can run code faster in some case (by suspending GC in some critical code and just do plain allocate and resume GC at a later time, and this is also how you make it more real-time compatible), it can also help curb fundamental security issues such as dangling pointers and use-after-free.
GC is also not the blame to the bloated size of your app, Nim [1], for example, is a language with GC/runtime while being lightweight. Another honorable mention would be Haxe [2] for gamedev, where it can generate much more compelling C++ code that the binary size is just slightly bigger to what you normally do with C++ while having much less lines needed to code. And it has a tracing GC.
So I do think GC-enabled language can be like C/C++/Rust. Even if there is a binary and performance difference, it won't be huge. But the way it makes your program safer by a huge margin and your programmer less mentally pain, makes having GC a huge difference.
By the way, even smart pointers/move semantics and ownership are one kind of GC (by leveraging linear/affine logic to ensure resources will not drop out of its controllable/life phase commonly called lifetime), so most of the time what I refer to GC is more specifically tracing GC where mark-and-sweep algorithms that usually need to stop-the-world is indeed a fundamental problem in GC design especially for multi-core platform which is going more and more popular nowadays.
[1]: https://nim-lang.org [2]: https://haxe.org