1

私は数週間前に DI フレームワークで作業を始めました (楽しみのため)。それを構築しているときに、次の問題に遭遇しました。基本的に、私たちのほとんどは、DI フレームワークを使用して、実装ではなくインターフェイスに対してコーディングすることに関心を持っています。私はこの SOLID の原則に完全に同意します。私自身、DI フレームワークの大ファン/ユーザーです。たとえば、.NET はすぐに使える DI 機能を提供しないためです。確かに MEF と Unity がありますが、それらは外部ライブラリです。

現状では、DI を使用したい場合は、サードパーティのライブラリを使用し、プロジェクトがそれを参照していることを確認する必要があります。それとは別に、アプリケーションをライブラリで発生する可能性のある実行時の問題にさらす必要があります。例外。

DI ライブラリを使用するコンポーネントがそれを参照する必要があるという事実を解決することはできませんが (少なくともまだ)、例外の解決策が必要です: DI ライブラリ内で発生する未処理の例外は、ライブラリ内にとどまる必要があります。クライアントアプリケーションに伝播しないということです。はい、適切に設計されたライブラリはすべての例外を処理する必要がありますが、ソフトウェアは完全ではありません。

これを実現する最も簡単な方法は、ApplicationDomains を使用し、プロセス間通信に名前付きパイプで .Net Remoting を使用することです。皆さんから知っておく必要があるのは、他のツール/プロセスを使用してこの種の分離を作成する他の方法があるかどうかです.

ありがとう

アップデート

もう少し調べてみると、これは .Net Remoting を直接使用しなくても簡単に実装できることがわかりました。

public interface IRuntime
{
    bool Run();
}

public class Runtime : MarshalByRefObject, IRuntime
{
    public bool Run()
    {
        throw new NotImplementedException();
    }
}

class Program
{
    static void Main(string[] args)
    {
        var domainSetup = new AppDomainSetup()
        {
            ApplicationBase = AppDomain.CurrentDomain.SetupInformation.ApplicationBase,
            ConfigurationFile = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile,
            ApplicationName = AppDomain.CurrentDomain.SetupInformation.ApplicationName,
            LoaderOptimization = LoaderOptimization.MultiDomainHost
        };

        var domain = AppDomain.CreateDomain("Your Child AppDomain", null, domainSetup);

        domain.FirstChanceException += (sender, e) =>
        { };

        Task.Factory.StartNew(() => domain.DoCallBack(() => new Runtime().Run()));

        Console.ReadKey();
    }
}

上記のサンプル コードは、私のニーズを満たしているようです。

ありがとう

4

0 に答える 0