The following files demonstrate a couple of ways to hook up a dbId
field across all your Node implementing types.
The first approach is to use the custom [NodeEx]
(instead of [Node]
) on annotation-based types and the .AsNodeEx(...)
extension method for fluent-style configuration.
The second approach is to use [Node]
as usual, and the standard ext methods (ImplementsNode
, IdField
, ResolveNode
) from HC, but add a type interceptor to find node-implementing types and try determine the id field's backing member by convention, adding the dbId
field from there.
IMO, on v12 or lower at least, the first approach (although it requires you to use non-framework stuff and remember that, and is a bit more code) is the way to go for two reasons.
- Because we're being given information about the id field's member (rather than trying to determine it from convention), there's no chance they could fall out of sync (e.g. doing
[Node(IdField = "CompletlyRandomjbsadfbasdf")]
won't cause the type interceptor to error. - (nit) It adds the
dbId
field before/next to your node'sid
field, rather than at the end as the type interceptor does. So it's a bit cleaner.
That said, I've since learned (or believe anyway) that the Node attribute stores some context data about things it determines are node-related, like which member is for the id field. So if we can register our type interceptor after that, we could use that context knowledge to remove the issue 1 mentioned.
Or I just contrib to HC core and make dbId a first-class citizen.
For v12 the helpers could be:
the usage (in code-first) is like the following: