À l'aide de l'Unité DI avec une Application Console

Im essayant d'obtenir l'Unité de travailler avec mon application console, cependant.. toutes les propriétés que j'essaie de la dépendance injecter sont toujours nulles.

C'est mon code:

Programme.cs

namespace .Presentation.Console
{
    class Program
    {
        static void Main(string[] args)
        {
            var mainThread = new MainThread();
        }
    }
}

MainThread.cs

namespace xxxx.Presentation.Console
{
    public class MainThread
    {
        public IUnitOfWork UnitOfWork { get; set; }

        public IMapper Mapper { get; set; }

        public MainThread()
        {
            Mapper.RegisterMappings();
        }
    }
}

App.config

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration"/>
  </configSections>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5.1" />
  </startup>
  <unity xmlns="http://schemas.microsoft.com/practices/2010/unity">
    <alias alias="IDataAccess" type="UnityFramework.IDataAccess, UnityFramework" />
    <namespace name="UnityFramework" />
    <assembly name="UnityFramework" />
    <container>
      <types>

        <type type="IMapper" mapTo="xxxx.Core.Parse.ParseMapper" />

      </types>
    </container>
  </unity>
</configuration>

App.la config est mis à Copier Toujours

Où Mapper est retourné comme nul dans ce cas (et je suppose UnitOfWork est ainsi)

Dois-je faire autre chose? Ajouter quelque chose à l'app.config? Ai-je raté quelque chose?

Merci d'avance!

Br,
Inx

S'il vous plaît, veuillez, s'il vous plaît ne pas utiliser les annotations. Le conteneur sait sur les composants, mais composants ne doit jamais savoir sur le conteneur.
En tout cas, le problème est que l'Unité ne va pas et de "remplir" propriétés " (beaucoup moins statique). Il remplit, dans les dépendances (ie. exemple propriétés, des arguments du constructeur) lors de la résolution des composants. Le niveau le plus haut (ou "racine") de l'objet/les objets dans le graphique, peut - être la "UoW" ici? - sont créés avec le manuel des appels à Résoudre. Certains d'intégration contextes (par exemple. WCF/WebAPI/MVC) peut déjà résoudre les causes de la violence, mais un simple programme ne dispose pas d'une telle intégration du contexte.
Donc, vous dites que les annotations ne sont pas nécessaires? J'ai aussi changé mon code un peu.. pourriez vous s'il vous plaît jetez un oeil et me dire ce qui est faux.. mauvais mise à jour le post dans quelques minutes.
Ils sont en effet pas nécessaire - et l'Unité est l'un des rares Cio conteneurs a même! Au lieu d'avoir le composant de la demande pour des propriétés spécifiques à remplir, que l'enregistrement d'approvisionnement de l'information. (Je recommande l'utilisation de la norme constructeur injection comme à l'époque, pas de travail supplémentaire doit être fait.) Pour obtenir l'Unité d'injecter des dépendances vous créer une instance avec container.Resolve (ou ont-il automatiquement réglée dans le cadre d'une chaîne).. l'Unité ne fait rien pour new.

OriginalL'auteur Inx51 | 2015-03-17

  1. 12

    L'unité seulement fournitures de dépendances pour les composants obtenus par Resolve ou lors de la résolution de la sous-dépendances. La "racine" ou les composants doivent être obtenus à partir du conteneur manuellement.

    À l'aide de new Program serait pas fournir automatiquement les dépendances parce qu'il ignore l'Unité de conteneur.

    static class ProgramEntry
{
    static void Main(string[] args)
    {
        var unity = CreateUnityContainerAndRegisterComponents();
        //Explicitly Resolve the "root" component or components
        var program = unity.Resolve<Program>();
        program.Run();
    }
}

public class Program
{
    readonly Ix _x;

    //These dependencies will be automatically resolved
    //(and in this case supplied to the constructor)
    public Program(IMapper mapper, Ix x)
    {
        //Use dependencies
        mapper.RegisterMappings();

        //Assign any relevant properties, etc.
        _x = x;
    }

    //Do actual work here
    public void Run() {
        _x.DoStuff();
    }
}

    Je préfère basées sur le code d'enregistrement pour la plupart des tâches.

    • Je recommande pas à l'aide d'attributs, bien qu'ils "fonctionnent" de si à la suite de la Resolve schéma ci-dessus. La "racine" des objets doit être résolu manuellement.

      Le problème avec les attributs de ces dépendances sur l'Unité autant pour "inverser"!

      Constructeur d'Injection (comme montré) est automatique/default. Voir Setter de la propriété de l'injection dans l'Unité, sans attributs si la Propriété de l'Injection est préféré.

    • Je serais probablement résoudre une Usine (ou Func<UoW>) pour créer une UoW et de l'approvisionnement en bas de la pile des appels contexte (ie. passer à des méthodes), le cas échéant. L'application peut avoir beaucoup de différents UoWs pendant une seule exécution. Dans ce cas, vous pourriez également être intéressé par la création des étendues.

    • J'aurais aussi pu utiliser une factory pour créer un pré-configuré IMapper objet lorsqu'il est résolu au lieu d'utiliser RegisterMappings par la suite.

    OriginalL'auteur user2864740