Comment by fabian2k

1 hour ago

The only case I've used them was to mark classes that I need to find via reflection and do something with them. For example a migration system where you want to load all migrations that are defined and check if you need to run them. Of course you don't really need an attribute for that, but I find it helpful to leaven a marker on the class that there's something else going on there.

To solve this problem I have seen the following pattern:

1. Create an abstract base class named MigrationBaseClass 2. Have all migrations classes inherit from MigrationBaseClass 3. Use .Net Reflection to get all types that inherit from MigrationBaseClass 4. Do something with these types.

  • yeah, there's plenty of ways to do that. I like having the attribute there so that there is a strong hint that some magic is happening somewhere with that class.

  • Doesn't even need to be an abstract base class. It's just as easy to use reflection to find all implementations in an assembly of an IMigration interface.

FastEndpoints does this for you with Validators as an example... It can be abstracted cleanly.