オープンソースのない拡張性

Question

私の会社は現在、C＃で大規模な多層ソフトウェアパッケージを作成中です。私たちはSOAアプローチを採用しましたが、プログラミング知識を持つユーザーが拡張性を持たせる方法について助言を得ている人がいるかどうかは疑問でした。

これには、特定のプラグインを使用できるようにするための運用システムの管理者による承認と、実際のプラグインのアーキテクチャ自体が含まれます。

一般的なタスクを実行したり、ユーザーインターフェイスのレイアウトを変更したり（WPFで書かれた）、新しい機能を追加するためのスクリプトを書くことができます。誰かがこれを実装する方法の提案を持っているのですか、あるいはこの種のことをするための知識をどこから得られるかを知っていますか？

私はこれがソフトウェアのオープンソースを流通の制限付きライセンスでリリースするのに最適なコーナーケースだと思っていましたが、私はソースコードへの競争のアクセスを許可することに熱心ではありません。

ありがとうございました。

EDIT：私はなぜ私がした答えを選んだのかを説明することを明確にしました。私は私の会社（すなわちクライアント）の外部のプロダクション管理者を指していて、C＃の完全な知識を持たなくても簡単に物事を自動化/スクリプト化できるようにしています（ほとんど制限付きのプログラミング経験） - 私はDSLをもっと考えていました。これは到達目標外である可能性があり、Managed Extensibility Frameworkはこれまでのところ最高の妥協点を提供しているようです。

Answer 1

MicrosoftのMEFイニシアチブを見ていきます。これは、アプリケーションに拡張性を加えるためのフレームワークです。今はベータ版だが、.Net 4.0の一部でなければならない。

マイクロソフトではソースを共有しているため、実装されてどのように実装されているかを見ることができます。だから、基本的にあなたの拡張性の枠組みは誰もが見ることができるように開いていますが、アプリケーションコードやプラグインコードを公開することはありません。

Answer 2

オープンソースはこの状況では怖いアイデアだと私は同意します。プロダクション管理者の承認 - あなたの会社内の管理者ですか、外部ですか？

個人的には、継承（ソースを与えずに第三者がコードをサブクラス化できるようにする）と非常に慎重に指定されたアクセス修飾子を使用して拡張性を可能にすることを検討します。

Answer 3

インターフェイスを使用してください。すべてのプラグインが実装しなければならないIPluginを定義し、よく定義されたメッセージングレイヤーを使用してプラグインがメインプログラムを変更できるようにします。ユーザプラグインに大きく依存するMediaportalやMeediosのようなプログラムを見たいかもしれません。

Answer 4

スティーブが述べたように、インタフェースを使用するのはおそらく道のりです。クライアントに使用させたいインターフェイスセットを設計し、プラグインのエントリポイントとプラグインの通信モデルを設計する必要があります。 Steveの提案に加えて、Eclipseプロジェクトを見てみることもできます。彼らは非常によく定義されたプラグインのアーキテクチャを持っており、Javaで書かれているにもかかわらず、それを見て価値があるかもしれません。

もう1つのアプローチは、スクリプト言語で使用できるAPIを設計することです。 IronPythonとBooは、C＃でうまく動作する動的スクリプト言語です。このアプローチでは、クライアントはアプリケーションと対話してアプリケーションを拡張するためのスクリプトを書くことができます。このアプローチは、フルプラグインシステムに比べて軽量なソリューションです。

Answer 5

オープンソースは、製品を拡張可能にするために、いかなる形や形でも必要ではありません。

Answer 6

マイクロソフトではすでにこれを行っており、ユーザーが定義したレイアウト、スクリプト作成性、チャート、カスタマイズ可能なUIなど、すべての属性を持つReporting Servicesを実現しています。これには、ダウンロード可能なIDEが含まれます。ソースコードへのアクセスは提供されていませんが、拡張性のフックで完全に覆われています。ソースコードがないと、クローズカップリングが抑制され、SOAの考え方が促進されます。

Answer 7

私たちは現在同様の状況にあります。私たちは、人々がデータレベルでライブ接続を作成したいかもしれないさまざまなシナリオを特定しました。その場合、彼らはデータを要求してインポートするためにシヌーウェブサービスにアクセスすることができます。

ある時点で、カスタムユーザーインターフェイス（このケースではSilverlight 2）が必要な場合があります。このシナリオでは、基本クラスを提供し、モジュールを中央リポジトリに登録させることができます。その後、セキュリティ、フォーム、ビヘイビア、サービスとの相互作用など、一貫した方法でアプリケーションに統合されます。