3 ms·

What's so bad about using reflection and attributes in this context?

andix 5y ago
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.
- arethuza 5y ago
  "if you load the routes from a database" Serious question (honestly not being snarky) - why would you want to do that?
  - andix 5y ago
    I don’t know, nobody needs more the 640k of RAM, right? Maybe you have multiple modules, and depending on the configuration the routing changes. Or feature flags, that enable a breaking api change. Or a stupid customer that pays you a million dollar for custom routes. But what benefit do the attributes bring? You need to learn them by heart, on builders Intellisense can help you.
    - arethuza 5y ago
      Well yes - if you need some kind of dynamically configurable routing then attributes aren't a good fit. I like the fact they are there right next to the relevant method...
      - andix 5y ago
        Another thing is, that attributes totally opinionate your code. You pull in a framework into your code. If you - for example - write one controller you want to use with multiple frameworks (ASP.NET Core or Nancy), you need one controller per framework, just for the attributes. I always found them more annoying then helpful. Most people seem to see it that way. Most frameworks are moving away from attributes for a good reason.
  - aliswe 5y ago
    CMS:s do that! Any kind of editorial content being served is a use case.
- merb 5y ago
  btw. in .net core you can either use attributes or builders to create your routes or even more stuff. at least since (i think) 3.0. and if that is not a great fit you can actually build your own routing by creating a middleware (btw. the endpoint routing stuff is just a middleware)
jayd16 5y ago
Probably attributes have to be added to classes, builders can receive types through a method. If you can't change the code, you can't use attributes. Construction time is also probably the safest place to inject dependencies.
WorldMaker 5y ago
1) Startup time: reflection can take a ton of time to run. It only needs to happen once, but especially as more and more web servers move to idle models where cold startup time matter rather than just holding on to a warm service, it's not always as amortized as before. 2) AOT compilation support/size: relying on Reflection APIs means that much more metadata/symbol data has to be preserved during an AOT compilation. This impacts metadata that needs to be passed to the AOT pass and final build size from the AOT. Some web applications are interested in delivering full, streamlined AOT builds rather than typical .NET CLR applications (and JIT compilation).

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.

arethuza 5y ago
"if you load the routes from a database" Serious question (honestly not being snarky) - why would you want to do that?
- andix 5y ago
  I don’t know, nobody needs more the 640k of RAM, right? Maybe you have multiple modules, and depending on the configuration the routing changes. Or feature flags, that enable a breaking api change. Or a stupid customer that pays you a million dollar for custom routes. But what benefit do the attributes bring? You need to learn them by heart, on builders Intellisense can help you.
  - arethuza 5y ago
    Well yes - if you need some kind of dynamically configurable routing then attributes aren't a good fit. I like the fact they are there right next to the relevant method...
    - andix 5y ago
      Another thing is, that attributes totally opinionate your code. You pull in a framework into your code. If you - for example - write one controller you want to use with multiple frameworks (ASP.NET Core or Nancy), you need one controller per framework, just for the attributes. I always found them more annoying then helpful. Most people seem to see it that way. Most frameworks are moving away from attributes for a good reason.
- aliswe 5y ago
  CMS:s do that! Any kind of editorial content being served is a use case.
merb 5y ago
btw. in .net core you can either use attributes or builders to create your routes or even more stuff. at least since (i think) 3.0. and if that is not a great fit you can actually build your own routing by creating a middleware (btw. the endpoint routing stuff is just a middleware)

jayd16 5y ago

Probably attributes have to be added to classes, builders can receive types through a method. If you can't change the code, you can't use attributes. Construction time is also probably the safest place to inject dependencies.

WorldMaker 5y ago

1) Startup time: reflection can take a ton of time to run. It only needs to happen once, but especially as more and more web servers move to idle models where cold startup time matter rather than just holding on to a warm service, it's not always as amortized as before. 2) AOT compilation support/size: relying on Reflection APIs means that much more metadata/symbol data has to be preserved during an AOT compilation. This impacts metadata that needs to be passed to the AOT pass and final build size from the AOT. Some web applications are interested in delivering full, streamlined AOT builds rather than typical .NET CLR applications (and JIT compilation).