Istanzia un motore da un secondo progetto senza avere un riferimento al secondo progetto causando un riferimento circolare?

Questo è esattamente ciò che i metodi di estensione sono per. Posso definire la fabbrica nel progetto Cinema con la sola firma del metodo. Posso definire un metodo di estensione in Cinema.Engine .

Esempio di codice qui sotto, che mostra come ottenere ciò usando i metodi di estensione. I quattro spazi dei nomi sono destinati a risiedere in quattro diversi progetti.

namespace Cinema {

    // Required for WCF
    public interface ICinema {
    }

    public sealed class CinemaFactory {
        // Singleton pattern to support extension methods. (Can't add extension methods to static classes.)
        private static readonly Lazy<CinemaFactory> LazyInstance = new Lazy<CinemaFactory> (() => new CinemaFactory());

        public static CinemaFactory Instance {
        get {
                return LazyInstance.Value;
            }
        }

        private CinemaFactory () {
        }

        public ICinema  GetCinema (EndpointAddress10 RemoteCinemaUri) {
            ICinema CinemaEngineInstance;

            // Get a reference from the WCF service...

            return CinemaEngineInstance;
        }
    }
}

namespace Cinema.Engine {
    using Cinema;

    public class CinemaEngine : ICinema {
    }

    // Add polymorphism to the class defined in a different project.
    public static class CinemaFactoryHelper {
        public static ICinema GetCinema (this CinemaFactory _This) {
            return new CinemaEngine ();
        }
    }
}

namespace Cinema.Client1 {
    using Cinema;

    public class Consumer1 {
        // Intellisense shows that there are no overloads to the GetCinema() method. Yay!
        private ICinema ref = CinemaFactory.Instance.GetCinema (EndpointAddress10.FromEndpointAddress (new EndpointAddress ("http://localhost"));
    }
}

namespace Cinema.Client2 {
    using Cinema;
    using Cinema.Engine; // Add visibility to the extension method that provides a local instance of the engine.

    public class Consumer2 {
        // Intellisense shows the method +1 overload. Yay!
        private ICinema ref = CinemaFactory.Instance.GetCinema ();
    }
}

Quindi, hai qualcosa di simile a questo:

public interface IWidget {}

public class RemoteWidget : IWidget {}
public class LocalWidget : IWidget {}

public class WidgetFactory
{
  public IWidget Create(Configuration configuration)
  {
      return new LocalWidget(configuration);
  }

  public IWidget Create(Uri origin)
  {
      return new RemoteWidget(origin);
  }
}

E, per qualche motivo, ora desideri distribuire WidgetFactory separatamente da LocalWidget . Come crei un WidgetFactory che non conosce al momento della compilazione quali implementazioni IWdidget sono disponibili o dove trovarle?

Hai alcune opzioni. Ad esempio:

• Scansione di una directory di estensioni, moduli o plug-in per DLL e caricali dinamicamente .
• Utilizza un framework DI che può eseguire il caricamento di alcune delle librerie dinamiche per te.
• Utilizza il Framework di estensibilità gestita .
• Metodi di estensione ... forse . Ho appena capito che potrebbe funzionare; Non riesco a pensare a come offhand.
• Consenti all'applicazione client di configurare WidgetFactory o registrare le implementazioni Widget disponibili. Questo è probabilmente il percorso di minima assunzione: il cliente può scegliere di utilizzare DI, MEF, metodi di estensioni, riflessione diretta, ecc. Non si sta imponendo molto in termini di architettura in questo modo.
• Allo stesso modo, fai in modo che% co_de accetti un parametro WidgetFactory.Create (potenzialmente come generico). Nel tuo caso, il tuo cliente sembra aver bisogno di sapere quale tipo ha bisogno di comunque . Quindi, questo può essere accettabile ...

O , cambia il tuo design: non considerare il progetto "Widget" come distribuibile; includilo nel tuo distribuibile. In tal caso, non inseriresti Type nel progetto "Widget", inseriresti WidgetFactory in.

Quindi, chiedi al cliente di fornire la fabbrica di cemento o crea alcune distro in base al modello di prezzo (presumo che sia ciò che sta guidando il bisogno di separazione). Ad esempio, IWidgetFactory , FreeDistro , StandardDistro ... Ciascuna di queste distro includerebbe solo riferimenti rigidi ai tipi concreti (e alle fabbriche) disponibili a quel "livello di supporto".

Molte opzioni ... Non tutte le opzioni si escludono a vicenda!