35 ms·

As an alternative to using additional framework layers, I'd recommend spending an afternoon familiarizing yourself with AspNetCore middleware - and HttpContext

As an alternative to using additional framework layers, I'd recommend spending an afternoon familiarizing yourself with AspNetCore middleware - and HttpContext in particular. Getting at the raw primitives can allow for you to throw away a lot of confusing boilerplate. Once you learn that everything that happens in the most complicated corners of web apps is ultimately dancing on top of HttpContext, you can dramatically simplify your life. Even things like web sockets and 3rd party auth are just a handful of lines on top. These abstractions are not scary to use. The Microsoft documentation is really poor with regard to guiding developers towards these simpler approaches. It's fairly obvious that they want you deep in the Azure complexity matrix. The only exception I have found to this perception is noted below [0]. Mastery here means you can avoid pulling down vendors' interpretations of how your entire application should be written. You can write whatever middleware per their specifications and make it fit your patterns perfectly. I recall what it was like allowing my auth vendor's ham-fisted libraries drive much of how my web app and DI had to be structured. [0]: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis?view=aspnetcore-8.0 https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m...

robertlagrant 2y ago
Yeah, it's so confusing because it talks about ASP. If Microsoft just named things after what they are, instead of branding them, it would be much better.
rqtwteye 2y ago
We have some APIs written with.NET Core and ASP.NET. They work pretty well but the number of dependency injections, overrides and options are starting to kill me. Basically you get the spaghetti code version of OO. Relevant behavior is spread out over many files and I find it really hard to figure out what's going on if I haven't written the code myself.
- cheschire 2y ago
  That's because it's not really OOP. If you're struggling with using the latest .NET conventions, then perhaps you are still thinking in terms of deep inheritance, polymorphism, constructors, and rich object models. The modern ASP.NET focus on repositories, middleware, service factories, and moving context around in data transfer objects lends itself to a different architecture and arrangement of code that more closely mirrors the stateless needs of the web, where not only are the front end and back end separate applications, but the client is entirely untrustworthy. That's very different than the expectations when OOP was originally envisioned.
  - rqtwteye 2y ago
    I don’t really care if it’s OOP by some definition or not. My point was that there are a lot of places where one can change the behavior of the app and it’s not easy to figure this out when you look at a codebase you don’t know yet.
    - metaltyphoon 2y ago
      > My point was that there are a lot of places where one can change the behavior of the app Could you be more specific? As I’m aware, all you need to look for is where DI is being messed with.
pjerem 2y ago
Yeah. I’ve been trained to aspnetcore in my previous job. Saying I wasn’t hyped is an understatement. Then I had to work with it for more than a year. I discovered two things : - 1 ) I was wrong : it’s a very good and really well designed framework. I have a huge respect for the engineers behind it. It’s easy to work on all the layers you need. It’s also easy to ignore every layers you don’t need. - 2) The documentation is awful. And I don’t mean the inline documentation : every method of the framework is very well documented in code. However the online docs, the one which should guide you and make the pieces click together is a real pain to navigate, is poorly written, and that’s when it exists. Fortunately I also discovered that there is a very welcoming community in the ecosystem. Mostly composed of people who discovered at their $job that the tech was indeed cool but that Microsoft is shitty when it comes to be friendly.
- radicalbyte 2y ago
  I've been using .Net since 2002, as my main framework since 2007 and have always stayed on the edge (as part of alt.net, the part of the community who pushed .net core and basically the entire .net team nowadays). So for the last 6 months I've been using golang. I really like it. Fast, simple, native.... but it's like using tonka toys compared to .net core. It's slower for webservices and everything is just more work. Yes being a wizard with .net and only decently productive in golang is a difference but that's not it. It's just nowhere near as mature as a language or ecosystem.
  - neonsunset 2y ago
    And it is moving so much faster in runtime/compiler improvements. Implementation wise, it outdoes the Go at things Go is renown for. The only last, and most critical piece of the puzzle that's missing is laser focus on simplicity of implementation. It is improving, but if you use generic composition and very terse writing style ala Rust traits and impl., pass data by `ref T`, occasionally manually manage the memory, you soon enough have people up in arms about this kind of unorthodox approach in the sphere of line of business applications (even when it tolerates that in other lower-level or just more limited languages, everything has to be abstracted away and very wordy).

robertlagrant 2y ago

Yeah, it's so confusing because it talks about ASP. If Microsoft just named things after what they are, instead of branding them, it would be much better.

rqtwteye 2y ago

We have some APIs written with.NET Core and ASP.NET. They work pretty well but the number of dependency injections, overrides and options are starting to kill me. Basically you get the spaghetti code version of OO. Relevant behavior is spread out over many files and I find it really hard to figure out what's going on if I haven't written the code myself.

cheschire 2y ago
That's because it's not really OOP. If you're struggling with using the latest .NET conventions, then perhaps you are still thinking in terms of deep inheritance, polymorphism, constructors, and rich object models. The modern ASP.NET focus on repositories, middleware, service factories, and moving context around in data transfer objects lends itself to a different architecture and arrangement of code that more closely mirrors the stateless needs of the web, where not only are the front end and back end separate applications, but the client is entirely untrustworthy. That's very different than the expectations when OOP was originally envisioned.
- rqtwteye 2y ago
  I don’t really care if it’s OOP by some definition or not. My point was that there are a lot of places where one can change the behavior of the app and it’s not easy to figure this out when you look at a codebase you don’t know yet.
  - metaltyphoon 2y ago
    > My point was that there are a lot of places where one can change the behavior of the app Could you be more specific? As I’m aware, all you need to look for is where DI is being messed with.

pjerem 2y ago

Yeah. I’ve been trained to aspnetcore in my previous job. Saying I wasn’t hyped is an understatement. Then I had to work with it for more than a year. I discovered two things : - 1 ) I was wrong : it’s a very good and really well designed framework. I have a huge respect for the engineers behind it. It’s easy to work on all the layers you need. It’s also easy to ignore every layers you don’t need. - 2) The documentation is awful. And I don’t mean the inline documentation : every method of the framework is very well documented in code. However the online docs, the one which should guide you and make the pieces click together is a real pain to navigate, is poorly written, and that’s when it exists. Fortunately I also discovered that there is a very welcoming community in the ecosystem. Mostly composed of people who discovered at their $job that the tech was indeed cool but that Microsoft is shitty when it comes to be friendly.

radicalbyte 2y ago
I've been using .Net since 2002, as my main framework since 2007 and have always stayed on the edge (as part of alt.net, the part of the community who pushed .net core and basically the entire .net team nowadays). So for the last 6 months I've been using golang. I really like it. Fast, simple, native.... but it's like using tonka toys compared to .net core. It's slower for webservices and everything is just more work. Yes being a wizard with .net and only decently productive in golang is a difference but that's not it. It's just nowhere near as mature as a language or ecosystem.
- neonsunset 2y ago
  And it is moving so much faster in runtime/compiler improvements. Implementation wise, it outdoes the Go at things Go is renown for. The only last, and most critical piece of the puzzle that's missing is laser focus on simplicity of implementation. It is improving, but if you use generic composition and very terse writing style ala Rust traits and impl., pass data by `ref T`, occasionally manually manage the memory, you soon enough have people up in arms about this kind of unorthodox approach in the sphere of line of business applications (even when it tolerates that in other lower-level or just more limited languages, everything has to be abstracted away and very wordy).