Databases
StackOverflow2013
Postsdbo
POBest practices for DI in a library involving Types in attributes
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POBest practices for DI in a library involving Types in attributes
    primarykey
    data
    text
    <p>I'm working on a library that simplifies application configuration. Essentially, consumers of the library either decorate their configuration classes with attributes or they initialize the settings declaratively in code. It would be possible to specify 1 or more sources from which to read/write configuration properties (Accessors) or inherit a default from the class. For example, the following:</p> <pre><code>[ConfigurationNamespace(DefaultAccessors = new Type[] { typeof(AppSettingsAccessor) })] public class ClientConfiguration : Configuration&lt;IClientConfiguration&gt; { [ConfigurationItem(Accessors = new Type[] { typeof((RegistryAccessor)) })] public bool BypassCertificateVerification { get; set; } } </code></pre> <p>would be equivalent to</p> <pre><code>var config = new Configuration&lt;IClientConfiguration&gt;(); config.SetDefaultAccessors(new[] { typeof(AppSettingsAccessor) }); config.SetPropertyAccessors( property: x =&gt; x.BypassCertificateVerification, accessors: new[] { typeof(RegistryAccessor) } ); </code></pre> <p>The Accessors deal with reading &amp; writing from various sources (AppSettings, registry, .ini, etc., etc.). I want to allow consumers to extend the capabilities to meet their needs. I'd like to keep it IoC container agnostic. The Type[] constraint is given to me because I can't specify types in attributes due to compile-time vs. runtime issues.</p> <p>Is there a way to have a default mechanism for instantiating these (e.g., something based on Activator.CreateInstance) but also allow the consuming code to instantiate these accessors at runtime <em>without</em> using the service locator/dependency resolver pattern? I've been reading a lot about why the service locator/dependency resolver pattern is an evil anti-pattern, but I can't figure out a better tool for the job. I see the MVC framework and SignalR libraries using dependency resolvers. Are they evil 100% of the time or is this an edge case? As far as I can tell, the abstract factory pattern won't cut it since it doesn't like Type parameters.</p> <p>In this particular case, the attribute-based configuration will be more useful than the declarative approach, so I don't want to abandon my Configuration attributes (which would allow me to change Type to IConfigurationAccessor and switch to a factory approach).</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USscottt732
    1. USscottt732
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POBest practices for DI in a library involving Types in attributes
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POBest practices for DI in a library involving Types in attributes
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POBest practices for DI in a library involving Types in attributes
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload