Idea - possibly a bad one - visual studio extension that hits a database to display possible values to supply as a method argument. With caching of course..

I'm thinking along the lines of permissions in a database that at some point have to be hard coded against code to enforce them. Stuff like that.

Possible or beyond stupid?

That's entity framework?

Usually a bad idea to couple domain interface design to database schema.

I mean actual records, not schema

@craig939393
You should never have to hard code coincidental data. If it can't be in an enum, it should bind using an abstraction that represents a possible value and a configuration that indicates its usage (decoupling). The policy is then evaluated against the cached data.

The prognosticated method of compiling to known values at a point in time is one of the reasons sitecore is such a disaster.

True but but then you have an enum or static class with constant values where the values are hard coded and noticing forces them to stay in sync with values in the database.

@craig939393
Lemme give this another shot:

- Data in the database is "runtime data"
- Everything in code is "design time" data (basis of metaprogramming)

Looking into the database at design time means that your data will be static to the time it was compiled.

What you want to do is create:
- An instance, injectable class that represents the current values in the database. This is persisted in memory, has a readonly and a writeonly interface, similar to an Rx subject. With proper aggregation, it could actually be an RxJs subject. Some poller would bind the update interfacev (write only), observers would bind the read interface.
- An instance injectable class that represents a 3-tuple map of the value that has been configured, and the policy it binds to, and the artifact it binds to

These two things represent the linkage between the policy-applicable structures (endpoints, operations, dataflows, etc) that are defined at design time, and the values that exist in the database.

A second table is added to reflect the values persisted from the class that binds the value, identify and policy tuple. The persistence is then maintained.

An event surfaces within the application (Rx, MassTransit, RabbitMq, NServiceBus, Kafka, whatever your poison is) and the in-memory cache updates.

A user (admin, whichever role you want) is presented with an interface (ui, swagger endpoint, cli, httpie, whatever) that allows them to configure the the 3-tuple.

A collection of those tuples is maintained inside a ConcurrentDictionary for O(1) access of policy tuples by identity. This is what gets updated when the configuration mutates, and builds into memory on startup. There is also the option to share this via redis.

This design is concurrent, threadsafe, one-way data, and if done right, immutable. It will be as current as the event stream, and can also be implementing with timecoded tombstoning and force recycling. That's a story for another book.

@SortOfTested this is quite an advanced answer for me so I don't really understand if this is a design for enforcement of policies at runtime, or a marketplace extension. Will have to go stretch my brain for bit to understand that be honest.

Thank you for the advice! Will make sure it's not wasted.

@SortOfTested Liked for the effort you made to give an honest objective to a person you don't know.