3 ms·

> This has always seemed way more maintainable to me. Even microsoft has added the ability to do these quick and dirty HTTP routing methods along with top level

> This has always seemed way more maintainable to me. Even microsoft has added the ability to do these quick and dirty HTTP routing methods along with top level statements. Many people (myself included) hate decorators. Keep my code declarative and free of black magic, please. This pattern also conflates class structure with route structure. What if I wanted to assign a method in this class to another base route? You end up with routing strewn all over the application.

shortrounddev2 3y ago
There's nothing "black magic" about them; they're very well documented features in Java, C#, and Python. They're officially experimental in Typescript but they're so heavily relied upon I can't imagine them getting deprecated
- ramesh31 3y ago
  >There's nothing "black magic" about them; they're very well documented features in Java, C#, and Python. Sure there is. It's metaprogramming. Anyone in the world who can read code can understand this immediately: app.get('/', (req, res) => { res.send('hello world') }) Throw decorators in the mix, and now I need to learn exactly what this specific environment is doing with those annotations. I have absolutely no way of understanding it at a glance. And you're now also stuck with vendor lockin to whatever framework/compiler was using them, and your code can no longer be fully isolated and unit tested without the framework.
  - shortrounddev2 3y ago
    Your complaint is that you have to understand your web framework before writing a program in it? Is that not the case with ALL web frameworks? > And you're now also stuck with vendor lockin to whatever framework/compiler was using them I don't understand. If you choose a web framework, you are locked in to developing things in that framework from now on. In what world do companies try to change web frameworks without having to change any of the underlying code? In what world would they want to do so?
    - ramesh31 3y ago
      >Your complaint is that you have to understand your web framework before writing a program in it? Is that not the case with ALL web frameworks? My complaint is that I don't want things in my code affecting my code that aren't code. Most web frameworks avoid this, while the more enterprise stuff like Spring, Dotnet, et. al seem to lean into it. It's kind of the same argument as SQL stored procs. Should you rely on embedding your business logic directly into the runtime? Probably not. Ultimately it's just personal preference. But if I can't compile something in my head at a glance, it shouldn't be a part of the codebase IMO.
      - shortrounddev2 3y ago
        > Most web frameworks avoid this I don't know if that's true, but I doubt it. > My complaint is that I don't want things in my code affecting my code that aren't code Many things affect your code under the hood that you don't see. There is no difference between using a decorator/attribute and having a config.json file for other things. > while the more enterprise stuff like Spring, Dotnet, et. al seem to lean into it. Because they are responsible for larger services which need to be more maintainable and stable. > But if I can't compile something in my head at a glance, it shouldn't be a part of the codebase IMO. This would preclude ever using a programming language or framework which you don't already know. You have been taught to write web services in one particular way; the fact that you don't know other ways doesn't make them "unreadable", it just means you don't know how to read it
    - bborud 3y ago
      No, having to spend months learning how web frameworks are going to deal with that piece of code is not a good thing. It means that the code is readable only to those who have spent a lot of time working with that framework. And it is one thing to be able to guess what is going on, if you are only superficially familiar with the framework. It is another thing entirely to know enough to be able to debug the code or to make changes without stuff breaking. And he does have a point about vendor lock-in. I tend to classify these kinds of frameworks as "cancerous" - as they metastasize and define how you can express yourself, and paint you into a corner where it gets really hard to rid your codebase of the framework should that be necessary. Part of my job in the past has to be technical due dil for M&A. This kind of design approach usually results in a red flag if a major part of the valuation is the codebase.
- whodev 3y ago
  > // Middleware automatically routes "/Foo" to FooController I don't know why, but I truly do not like this. So if I create a "HelloController" class does the middleware just start automatically routing "/hello" to it?
  - shortrounddev2 3y ago
    Yes
  - halter73 3y ago
    ASP.NET Core can easily route "/hello" to HelloController.Index(), but it's not exactly automatic. The controller library adds routes to the routing middleware in a call to MapControllerRoute the app developer must make during startup which specifies a pattern. app.MapControllerRoute( name: "default", pattern: "{controller=Home}/{action=Index}/{id?}"); https://learn.microsoft.com/en-us/aspnet/core/mvc/controllers/routing?view=aspnetcore-7.0#conventional-routing https://learn.microsoft.com/en-us/aspnet/core/mvc/controller... If you don't call one of the MapController methods, requests will not be routed to controllers even if they exist in the same project.

shortrounddev2 3y ago

There's nothing "black magic" about them; they're very well documented features in Java, C#, and Python. They're officially experimental in Typescript but they're so heavily relied upon I can't imagine them getting deprecated

ramesh31 3y ago
>There's nothing "black magic" about them; they're very well documented features in Java, C#, and Python. Sure there is. It's metaprogramming. Anyone in the world who can read code can understand this immediately: app.get('/', (req, res) => { res.send('hello world') }) Throw decorators in the mix, and now I need to learn exactly what this specific environment is doing with those annotations. I have absolutely no way of understanding it at a glance. And you're now also stuck with vendor lockin to whatever framework/compiler was using them, and your code can no longer be fully isolated and unit tested without the framework.
- shortrounddev2 3y ago
  Your complaint is that you have to understand your web framework before writing a program in it? Is that not the case with ALL web frameworks? > And you're now also stuck with vendor lockin to whatever framework/compiler was using them I don't understand. If you choose a web framework, you are locked in to developing things in that framework from now on. In what world do companies try to change web frameworks without having to change any of the underlying code? In what world would they want to do so?
  - ramesh31 3y ago
    >Your complaint is that you have to understand your web framework before writing a program in it? Is that not the case with ALL web frameworks? My complaint is that I don't want things in my code affecting my code that aren't code. Most web frameworks avoid this, while the more enterprise stuff like Spring, Dotnet, et. al seem to lean into it. It's kind of the same argument as SQL stored procs. Should you rely on embedding your business logic directly into the runtime? Probably not. Ultimately it's just personal preference. But if I can't compile something in my head at a glance, it shouldn't be a part of the codebase IMO.
    - shortrounddev2 3y ago
      > Most web frameworks avoid this I don't know if that's true, but I doubt it. > My complaint is that I don't want things in my code affecting my code that aren't code Many things affect your code under the hood that you don't see. There is no difference between using a decorator/attribute and having a config.json file for other things. > while the more enterprise stuff like Spring, Dotnet, et. al seem to lean into it. Because they are responsible for larger services which need to be more maintainable and stable. > But if I can't compile something in my head at a glance, it shouldn't be a part of the codebase IMO. This would preclude ever using a programming language or framework which you don't already know. You have been taught to write web services in one particular way; the fact that you don't know other ways doesn't make them "unreadable", it just means you don't know how to read it
  - bborud 3y ago
    No, having to spend months learning how web frameworks are going to deal with that piece of code is not a good thing. It means that the code is readable only to those who have spent a lot of time working with that framework. And it is one thing to be able to guess what is going on, if you are only superficially familiar with the framework. It is another thing entirely to know enough to be able to debug the code or to make changes without stuff breaking. And he does have a point about vendor lock-in. I tend to classify these kinds of frameworks as "cancerous" - as they metastasize and define how you can express yourself, and paint you into a corner where it gets really hard to rid your codebase of the framework should that be necessary. Part of my job in the past has to be technical due dil for M&A. This kind of design approach usually results in a red flag if a major part of the valuation is the codebase.
whodev 3y ago
> // Middleware automatically routes "/Foo" to FooController I don't know why, but I truly do not like this. So if I create a "HelloController" class does the middleware just start automatically routing "/hello" to it?
- shortrounddev2 3y ago
  Yes
- halter73 3y ago
  ASP.NET Core can easily route "/hello" to HelloController.Index(), but it's not exactly automatic. The controller library adds routes to the routing middleware in a call to MapControllerRoute the app developer must make during startup which specifies a pattern. app.MapControllerRoute( name: "default", pattern: "{controller=Home}/{action=Index}/{id?}"); https://learn.microsoft.com/en-us/aspnet/core/mvc/controllers/routing?view=aspnetcore-7.0#conventional-routing https://learn.microsoft.com/en-us/aspnet/core/mvc/controller... If you don't call one of the MapController methods, requests will not be routed to controllers even if they exist in the same project.