10

ユーザーが構成できるデータベース アプリケーションがあります。これらのオプションのいくつかは、さまざまな外部プラグイン システムから選択しています。

ベース プラグイン タイプがあり、データベース スキーマには同じフィールドを持つ同じプラグイン レコード タイプがあります。アプリケーションの開始時に（IoCコンテナーを介してPlugingMananger）プラグインをロードし、それらをデータベースにリンクする必要があります（基本的に、ディスク上のプラグインからデータベースにフィールドをコピーします）。

public interface IPlugin
{
    Guid Id{ get; }
    Version Version { get; }
    string Name { get; }
    string Description { get; }
}

プラグインは、 を使用して取得できますPlugingMananger.GetPlugin(Guid pluginId, Guid userId)。ユーザー ID は、プラグイン アクションを呼び出すことができる複数のユーザーのうちの 1 人の ID です。

既知のインターフェイスのセットは、特定の機能 (フォーマッター、外部データ、データ送信者など) に固有のアプリケーションによって事前に宣言されています。プラグインが不明なサービス インターフェイスを実装している場合、それは無視されます。

public interface IAccountsPlugin : IPlugin
{
    IEnumerable<SyncDto> GetData();
    bool Init();
    bool Shutdown();
}

PluginSettingAttributeプラグインは、マルチユーザー システムでユーザーごとに定義された設定属性を持つこともできます。これらのプロパティは、特定のユーザーに対してプラグインが取得されるときに設定PluginPropertyAttributeされ、すべてのユーザーに共通で、プラグインによって一度だけ読み取り専用に設定されるプロパティに対して設定されます。アプリケーションの起動時にプラグインが登録されたとき。

public class ExternalDataConnector : IAccountsPlugin
{
    public IEnumerable<AccountSyncDto> GetData() { return null; }
    public void Init() { }
    public void Shutdown() { }

    private string ExternalSystemUsername;
    // PluginSettingAttribute will create a row in the settings table, settingId
    // will be set to provided constructor parameter. this field will be written to
    // when a plugin is retrieved by the plugin manager with the value for the
    // requesting user that was retrieved from the database.
    [PluginSetting("ExternalSystemUsernameSettingName")]
    public string ExternalSystemUsername
    {
        get { return ExternalSystemUsername }
        set { ExternalSystemUsername = value; } 
    }

    // PluginPropertyAttribute will create a row in the attributes table common for all users
    [PluginProperty("ShortCodeName")]
    public string ShortCode
    {
        get { return "externaldata"; }
    }

    public Version PluginVersion
    {
        get { return new Version(1, 0, 0, 0); }
    }

    public string PluginName
    {
        get { return "Data connector"; }
    }

    public string PluginDescription
    {
        get { return "Connector for collecting data"; }
    }
}

ここに私の質問と私がガイダンスを求めている領域があります:

  1. IoC コンテナー内のプラグインをデータベースにリンクする上記の抽象化により、ユーザーはデータベース フィールドを選択できますCustomer.ExternalAccountsPlugin = idOfExternalPlugin。これは重く感じます - 他のシステムでこれを実現する簡単な方法はありますか (たとえば、SharePoint にはユーザー データベースによって参照されるプラグインがたくさんあります)。

  2. 私のアプリケーションは、コンパイル時に、それがサポートするインターフェースを指示し、他のすべてを無視します - 私はいくつかのシステムがオープンなプラグインで完全に拡張可能であると主張しているのを見てきました。再コンパイルせずに将来の更新を発行できるようにする2つのオプションはありますが、具体的なインターフェースを使用しますか?

  3. 私のプラグインにはメタデータ (PluginProperty または PluginSetting) が含まれている可能性があり、プラグイン メタデータ テーブル (linq クエリがより複雑になります) またはプラグイン データベース レコード行 (簡単な linq クエリ) に格納するのに最適な場所がわかりませんPluginManager.GetPluginsOfType<IAccounts>.Where(x => x.ShortCode = "externaldata").FirstOrDefault();。ベストプラクティスとして使用されますか?

  4. プラグインの機能とインターフェイスはデータベース スキーマに大きく依存しているため、特定のスキーマ リビジョンで使用するプラグインを制限するには、どのような方法が推奨されますか? このスキーマ リビジョンをデータベースの設定テーブルに 1 行として保持し、リリースごとに手動で更新しますか? プラグインは最大スキーマ バージョンをサポートしますか、それともアプリケーションは既知のプラグイン バージョンのリストをサポートしますか?

4

1 に答える 1

3

1) 申し訳ありませんが、よくわかりません。ただし、カスタムプラグインによってデータが作成または処理されるソフトウェアでは、説明した方法でプラグインを処理すると確信しています。ユーザーがデータをロードしたが、その特定のプラグインが見つからない場合、データは破損せず、ユーザーはそのデータを変更できません。（私の頭に浮かぶ例は、一般的な3Dソフトウェアです）

2）もちろん、非常に厳密なインターフェース実装のみを提供すると、プラグインの作成が大幅に制限されます。(例: Excel、新しいセル型を作成できません) それは悪いことでも良いことでもありません。プラグインの作成者に非常に特定のパイプによってのみデータにアクセスさせたい場合は、作成できるデータの種類を制限してください。そうすれば、それはあなたの設計に適合します。そうではなく、ソフトウェアを改善に向けてオープンにすることが目標である場合は、外部で使用するのに十分安全であると判断したいくつかのクラスとメソッドも公開する必要があります。(例: Maya、インターフェイスだけでなく、基本クラスから派生する新しいエンティティ タイプを作成できます)

3) まあ、それは多くのことに依存しますよね? データをシリアライズするとき、特定のプラグイン、ID、メタデータ、その他必要と判断したすべての情報を含むラッパーを作成できます。取得しやすいので、その方法で行きますが、必要なものにはそれが最善の方法ですか? これ以上の情報がなければなんとも言えません。

4) その良い例が Firefox です。バージョンの増分を小さくしても、プラグインの互換性は変わりません。プラグインが何を実装しているかを考慮して、プラグインがまだ有効であるかどうかをデータベースから中程度のバージョンインクリメントでテストします。プラグインが変更を実装していない場合でも、プラグインは有効です。メジャー バージョンの増分では、新しい定義を使用するためにすべてのプラグインを再コンパイルする必要があります。私の観点からは、これは開発者が常に再コンパイルできるわけではないという点で優れた中間点ですが、変更を事前に計画する必要があるため、メイン ソフトウェアの開発が少し難しくなります。アイデアは、ソフトウェア開発者とプラグイン開発者の間で PitA (お尻の痛み) 要因のバランスを取ることです。

ええと...それは私の2セントの長いコレクションでした。

于 2012-10-16T20:30:27.283 に答える