Force paresseux entité à la charge réelle de l'instance

À mon avis, plutôt que de résoudre ce problème, vous devriez plutôt repenser la conception de votre. Êtes-vous absolument sûr, que vous ne pouvez pas utiliser le polymorphisme dans cette situation - soit directement, prendre de l'entité responsable de l'opération que vous tentez d'accomplir ou d'utiliser des habitudes des visiteurs. Je suis tombé sur cette question à quelques reprises et toujours décidé à changer de design - il entraîné dans le code plus clair. Je vous suggère de faire de même, sauf si vous êtes absolument sûr que le fait de compter sur type est la meilleure solution.

Le problème

Afin de disposer d'exemple avec au moins une certaine ressemblance avec le monde réel, supposons que vous avez entités suivantes:

public abstract class Operation
{
    public virtual DateTime PerformedOn { get; set; }
    public virtual double Ammount { get; set; }
}

public class OutgoingTransfer : Operation
{
    public virtual string TargetAccount { get; set; }
}

public class AtmWithdrawal : Operation
{
    public virtual string AtmAddress { get; set; }
}

Il avait naturellement une petite partie de beaucoup plus grand modèle. Et maintenant, vous êtes confronté à un problème: pour chaque type de béton de l'Opération, il y a une autre façon de l'afficher:

private static void PrintOperation(Operation operation)
{
    Console.WriteLine("{0} - {1}", operation.PerformedOn,
                      operation.Ammount);
}

private static void PrintOperation(OutgoingTransfer operation)
{
    Console.WriteLine("{0}: {1}, target account: {2}",
                      operation.PerformedOn, operation.Ammount,
                      operation.TargetAccount);
}

private static void PrintOperation(AtmWithdrawal operation)
{
    Console.WriteLine("{0}: {1}, atm's address: {2}",
                      operation.PerformedOn, operation.Ammount,
                      operation.AtmAddress);
}

Simple, d'une surcharge de méthodes de travail dans le cas simple:

var transfer = new OutgoingTransfer
               {
                   Ammount = -1000,
                   PerformedOn = DateTime.Now.Date,
                   TargetAccount = "123123123"
               };

var withdrawal = new AtmWithdrawal
                 {
                     Ammount = -1000,
                     PerformedOn = DateTime.Now.Date,
                     AtmAddress = "Some address"
                 };

//works as intended
PrintOperation(transfer);
PrintOperation(withdrawal);

Malheureusement, les méthodes surchargées sont liés au moment de la compilation, donc dès que vous vous en présenter un tableau/liste/whatever des opérations, seulement un générique (Fonctionnement) surcharge sera appelée.

Operation[] operations = { transfer, withdrawal };
foreach (var operation in operations)
{
    PrintOperation(operation);
}

Il y a deux solutions à ce problème, et les deux ont des inconvénients. Vous pouvez introduire un résumé/méthode virtuelle dans l'Opération pour imprimer les informations de flux choisi. Mais ce sera un mélange de l'INTERFACE utilisateur préoccupations dans votre modèle, ce qui n'est pas acceptable pour vous (je vais vous montrer comment pouvez-vous améliorer cette solution pour répondre à vos attentes dans un instant).

Vous pouvez également créer beaucoup de ifs dans la forme de:

if(operation is (ConcreteType))
   PrintOperation((ConcreteType)operation);

Cette solution est laid et sujettes à erreur. Chaque fois que vous ajouter/modifier/supprimer le type de fonctionnement, vous devez aller à travers chaque endroit où vous avez utilisé ces hack et de le modifier. Et si vous manquez un seul endroit, vous aurez probablement seulement être capable d'attraper qu'à l'exécution, pas de stricts contrôles de compilation de certaines des erreurs (telles que le manque d'un sous-type).

En outre, cette solution échoue dès que vous introduisez tout type de proxy.

Comment proxy fonctionne

Le code ci-dessous est TRÈS simple proxy (dans cette mise en œuvre, il est même en tant que décorateur de modèle, mais ces modèles ne sont pas les mêmes en général. Il faudra un code supplémentaire pour distinguer ces deux modèles).

public class OperationProxy : Operation
{
    private readonly Operation m_innerOperation;

    public OperationProxy(Operation innerOperation)
    {
        if (innerOperation == null)
            throw new ArgumentNullException("innerOperation");
        m_innerOperation = innerOperation;
    }


    public override double Ammount
    {
        get { return m_innerOperation.Ammount; }
        set { m_innerOperation.Ammount = value; }
    }

    public override DateTime PerformedOn
    {
        get { return m_innerOperation.PerformedOn; }
        set { m_innerOperation.PerformedOn = value; }
    }
}

Comme vous pouvez le voir - il y a une seule classe de proxy pour l'ensemble de la hiérarchie. Pourquoi? Parce que vous devez écrire votre code dans un sens qui ne dépendent pas du type de béton uniquement sur l'abstraction. Cette procuration peut différer de l'entité de chargement dans le temps - peut-être que vous ne l'utilisez pas du tout? Peut-être que vous allez utiliser seulement 2 de 1000 entités? Pourquoi les charger ensuite?

Donc NHibernate utilise un proxy comme ci-dessus (beaucoup plus sophistiqué, tout de même) de reporter l'entité de chargement. Il pourrait créer 1 proxy par sous-type, mais il détruirait tout l'objet de lazy loading. Si vous regardez soigneusement à la façon dont NHibernate magasins de sous-classes, vous verrez, que, pour déterminer quel type d'entité, vous devez le charger. Il est donc impossible d'avoir béton procurations - vous ne pouvez avoir le plus abstrait, OperationProxy.

Bien la solution avec les fi c'est moche - c'était une solution. Maintenant, quand vous avez mis en place des procurations à votre problème - il n'est plus de travail. Cela nous laisse avec des polymorphes de la méthode, ce qui est inacceptable en raison du mélange de l'INTERFACE utilisateur la responsabilité de votre modèle. Nous allons remédier à cela.

Inversion de la dépendance et des habitudes des visiteurs

D'abord, nous allons jeter un oeil à la façon dont la solution avec des méthodes virtuelles ressemblerait (juste ajouté du code):

public abstract class Operation
{
    public abstract void PrintInformation();
}

public class OutgoingTransfer : Operation
{
    public override void PrintInformation()
    {
        Console.WriteLine("{0}: {1}, target account: {2}",
                      PerformedOn, Ammount, TargetAccount);
    }
}

public class AtmWithdrawal : Operation
{
    public override void PrintInformation()
    {
        Console.WriteLine("{0}: {1}, atm's address: {2}",
                          PerformedOn, Ammount, AtmAddress);
    }
}

public class OperationProxy : Operation
{
    public override void PrintInformation()
    {
        m_innerOperation.PrintInformation();
    }
}

Et maintenant, lorsque vous composez le:

Operation[] operations = { transfer, withdrawal, proxy };
foreach (var operation in operations)
{
    operation.PrintInformation();
}

tout fonctionne comme un charme.

Afin de supprimer cette INTERFACE utilisateur de la dépendance dans le modèle, nous allons créer une interface:

public interface IOperationVisitor
{
    void Visit(AtmWithdrawal operation);
    void Visit(OutgoingTransfer operation);
}

Nous allons modifier le modèle à dépendre de cette interface:

Et maintenant créer une mise en œuvre - ConsoleOutputOperationVisitor (j'ai supprimé PrintInformation méthodes):

public abstract class Operation
{
    public abstract void Accept(IOperationVisitor visitor);
}

public class OutgoingTransfer : Operation
{
    public override void Accept(IOperationVisitor visitor)
    {
        visitor.Visit(this);
    }
}

public class AtmWithdrawal : Operation
{
    public override void Accept(IOperationVisitor visitor)
    {
        visitor.Visit(this);
    }
}

public class OperationProxy : Operation
{
    public override void Accept(IOperationVisitor visitor)
    {
        m_innerOperation.Accept(visitor);
    }
}

Ce qui se passe ici? Lorsque vous appelez Accepter d'exploitation, et de passer d'un visiteur, la mise en œuvre de l'accepter, sera appelé, le cas échéant surcharge de la Visite de la méthode sera invoquée (compilateur peut déterminer le type de "ce"). Si vous combinez la "puissance" de méthodes virtuelles et les surcharges approprié de la méthode appelée. Comme vous pouvez le voir - maintenant, référence de l'INTERFACE utilisateur, ici, le modèle ne dépend que de l'interface, ce qui peut être inclus dans le modèle de la couche.

Alors maintenant, pour faire ce travail, une implémentation de l'interface:

 public class ConsoleOutputOperationVisitor : IOperationVisitor
 {
    #region IOperationVisitor Members
    public void Visit(AtmWithdrawal operation)
    {
        Console.WriteLine("{0}: {1}, atm's address: {2}",
                          operation.PerformedOn, operation.Ammount,
                          operation.AtmAddress);
    }

    public void Visit(OutgoingTransfer operation)
    {
        Console.WriteLine("{0}: {1}, target account: {2}",
                          operation.PerformedOn, operation.Ammount,
                          operation.TargetAccount);
    }

    #endregion
}

Et code:

Operation[] operations = { transfer, withdrawal, proxy };
foreach (var operation in operations)
{
    operation.Accept(visitor);
}

Je suis bien conscient que ce n'est pas une solution parfaite. Vous aurez encore à modifier l'interface et les visiteurs à mesure que vous ajoutez de nouveaux types. Mais vous obtenez moment de la compilation, de vérification et de ne jamais manquer de rien. Une chose qui serait très difficile à obtenir à l'aide de cette méthode est d'obtenir enfichables sous - types- mais je ne suis pas convaincu que cela est valable un scénario de toute façon. Vous aurez également à modifier ce modèle pour répondre à vos besoins dans le béton scénario, mais je vais laisser cela à vous.

Depuis le proxy est dérivée de la classe d'entité, vous pouvez probablement juste de vérifier entité.GetType().BaseType pour obtenir votre type défini.