A little background on where this question is coming from. In my current .NET application I'm working on some features related to archiving a certain type of business entity called a "Project". Depending on the situation what has to be archived, and the exact actions involved in archiving can vary wildly. My basic idea is to create an entity called an ArchiveSchedule which basically stores data saying this kind of project should be archived after this amount of time.
I want to encapsulate my queries for selecting all the objects to archive and the commands for actually archiving off into their own objects that inherit from some common interfaces. There will be multiple archive queries(select items based on various properties, or whether they've been archived before and later restored, etc), and multiple archive commands(ie commands that send data to different interfaces, some that perform deletes, etc.). What I'm considering doing is including on the ArchiveSchedule, references to the actual .NET type corresponding to the query and command I want to use for this schedule. Then when I want to actually run the queries and commands I use reflection to build up the object and execute the command or query.
Is this basic strategy of storing type information in the database and then using reflection to create the objects and inject dependencies an antipattern? Or is there a better way to do it?
Note:I know there are some issues with just storing the type name or namespace, because those might change during refactoring, but I believe those could be mitigated fairly easily using a GuidAttribute on the class definition and storing the guid instead, so I'm curious if there are more fundamental issues beyond that.