問題タブ [extensibility]

私はサンプル コンソール サービス ホストを作成しています。WCF スタックにプラグインして、新しいメッセージが到着したときにコンソールにメッセージを出力できるようにしたいと考えています。以前の呼び出しで)。これは、到着したメッセージが WCF によってキューに入れられるという私の仮定に基づいていますが、それは正しいですか?

さらに、これが重要な場合は netTcpBinding を使用しています。

Eclipse プラグイン フレームワークに匹敵するプラグイン ベースのアプリケーション フレームワークを探しています。

1. コアプラグイン管理フレームワーク(Equinox / OSGI)。拡張エンドポイントを宣言し、それらのエンドポイントにサービスを提供するプラグインを検出してロードする機能を提供します。(これは Dependency Injection とは異なりますが、確かに違いは微妙です。構成は高度に分散化されており、バージョン管理の問題があり、オンライン プラグイン リポジトリが含まれる可能性があります。私にとって最も重要なことは、ユーザーが簡単に追加できることです。基礎となるアーキテクチャ/構成ファイルについて何も知る必要のないプラグイン)
2. 同時実行サポート、コマンド、設定シート、メニュー、ツールバー、キーバインディングなど を備えた基本的なワークベンチシェルを提供するプラグインの多くのレイヤー。

これは RCP の表面をなぞっただけであり、それ自体がアプリケーションの基盤として機能することを意図しており、さらに多くのプラグインを作成/アセンブルして構築します。

ここ数日、ネットで拾ってきた情報…

私の知る限り、Java 用の Eclipse RCP の堅牢性と成熟度に遠く及ばないものは .NET の世界にはありませんが、1 番または 2 番のいずれかをうまくこなす候補がいくつかあります。

(WinForms と WPF のどちらを選択するかについて最終的な決定を下していないことにも言及しておく必要があります。そのため、候補となるフレームワークでの UI 結合のレベルも理解しようとしています。プラットフォームの結合とソース コードのライセンスについても疑問に思っています)。

オープンソースのものは一般に文書化されていませんが理解しやすいと言わざるを得ませんが、MS のものは通常より多くの文書がありますがアクセスしにくいため、MS テクノロジの多くでは、それらが実際に何をしているのか疑問に思っています。 、実用的な意味で。

これらは私が見つけたライブラリです：

SharpDevelop

私が最初に見たのは、#1 と #2 の両方を基本的な方法で実行する SharpDevelop でした (立派な SharpDevelop への侮辱ではありません - Eclipse RCPよりも基本的なことを意味します)。ただし、SharpDevelop はフレームワーク以上のアプリケーションであり、そこには基本的な仮定と制限があります (つまり、WinForms にある程度結合されています)。それでも、アプリケーションの基盤として CodeProject を使用する方法を説明する CodeProject に関する記事がいくつかあります。

System.Addins

System.Addins は、堅牢なアドイン読み込みフレームワークを提供することを意図しているようです。さまざまなレベルの信頼でアセンブリを読み込み、さらにはアウト プロセスを実行するための洗練されたオプションがいくつかあります。それは主にコードベースで、バージョン管理の問題から隔離するのに役立つ多くのアセンブリがあり、かなりコードが多いようです.Guidance Automationを使用して大量のコードを生成します.

これまでのところ、System.AddIns を使用して Eclipse RCP のようなものを構築する方法を説明している記事はあまり見つかりませんでした。また、多くの人がその複雑さに首を傾げているようです。

Mono.Addins

Mono.Addins は、System.Addins、SharpDevelop、MonoDevelop の影響を受けたようです。System.Addins の基本を提供しているように見えますが、プラグインの読み込みにはあまり洗練されていませんが、属性ベースの登録、XML マニフェスト、およびオンライン プラグイン リポジトリのインフラストラクチャにより、よりシンプルになっています。

これには、非常に優れた FAQ とドキュメントがあり、SharpDevelop や Eclipse のようなアーキテクチャを開発する方法を実際に描くのに役立つ、かなり堅牢な例のセットもあります。サンプルでは UI に GTK を使用していますが、フレームワーク自体は GTK に結合されていません。したがって、#1 (アドインのロード) はうまく機能しているように見え、#2 (ワークベンチ フレームワーク) への道を示しています。Mono.Addins は MonoDevelop から派生したように見えますが、MonoDevelop が優れたコア ワークベンチ フレームワークを提供するかどうかは実際には調べていません。

管理された拡張性フレームワーク

これは現時点で誰もが話していることであり、それが何をするのかが徐々に明らかになってきていますが、SOに関するいくつかの投稿を読んだ後でも、私はまだかなりあいまいです. System.Addins と "共存できる" というのが公式の言葉です。ただし、それを参照しておらず、その機能の一部を再現しているようです。したがって、これは System.Addins に代わる、よりシンプルでアクセスしやすい代替手段のように思えます。

属性ベースの配線を提供するという点で、Mono.Addins に似ているように見えます。属性ベースまたはディレクトリベースの「カタログ」を提供します。XML またはマニフェスト ベースのワイヤリングを提供していないようです。MEFはDIコンテナではないという明確化にもかかわらず、これまでのところ私は多くのドキュメントを見つけていません.

そのライセンスは公開されたばかりですが、WindowsBase を参照しています。それが Windows に結合されていることを意味するかどうかはわかりません。

アクロポリス

これが何であるかわかりません。それは MEF ですか、それともまだ来ているものですか?

複合アプリケーション ブロック

より多くのワークベンチ フレームワークを提供するように見える WPF および Winforms Composite Application ブロックがあります。私はこれらの経験がほとんどありませんが、ガイダンスオートメーションにかなり依存しているようで、明らかにUIレイヤーと結合しています. MEF をこれらのアプリケーション ブロックと組み合わせた例がいくつかあります。

ここで自分の質問に答えるために最善を尽くしましたが、実際には表面をなぞっただけであり、これらのフレームワークの経験はありません。うまくいけば、経験のあるフレームワークについてさらに詳細を追加できる人もいます。なんらかの比較マトリックスが得られれば素晴らしいと思います。

そのため、サービスとして実行するマルチテナント システムを構築しています。私たちはゼロから始めています。私たちは DDD に従っています。ドメインには (現時点で) ~20 個のエンティティがあり、後でさらに増える予定です。それは私たちによってホストされ、地理的に冗長であり (SQL クエリを除くすべての n+1 ;-))、柔軟な設計です (まあ、最後は私たち自身の要件であり、ビジネスではありません)。もちろん、必要に応じて簡単に変更できます）。私たちは .NET ベースで、バッキング ストアにリレーショナル データベースを使用します。オープンソースのツールやライブラリを使用することに (まったく) 反対しているわけではありません。

ビジネスに不可欠な機能の 1 つは、特定のエンティティがシステムのテナントによって拡張可能であることです。たとえば、クライアント A はエンティティ Foo に Title および Abstract プロパティを持たせたい場合がありますが、クライアント B はエンティティ Foo に Title Abstract ではなく Publish Date および Directed-By プロパティを持たせたい場合があります。

また、これを必要とするテナントのために複数の言語でデータをサポートする必要がある場合もあります。「静的」文字列と、エンティティにデータとして添付された文字列の両方。

そう。任意の数のフィールド (いくつかの共通のベースラインの上にあり、すべてのテナントが取得するこれらのエンティティに関する特定のものがあります)、クライアントによって定義可能です (データ型も定義できます)。データの翻訳の可能性 (エンティティを複製せずに、英語で 1 つのセットを設定せずに、フランス語で同じセットを設定せずに)。厳密に型指定された検索可能でクエリ可能なバッキング ストレージも (したがって、厳密に型指定され検索可能になる方法がない限り、XML フィールドに余分なものは入れられません)。高性能（ただし、二次的な要件として。機能は、必要に応じてハードウェアを購入するのに十分重要です）。

データ量？現在のシステムでは、「平均的な」クライアントには数百のエンティティがあり、「大きな」クライアントには数千のエンティティがあります。通常、要求はこれらのリストを 10 から 200 程度に絞り込んで表示します。最も一般的にやりたいことは、おそらく半ダースのエンティティ (新しいシステムでは拡張可能である必要があります) です。

その他のポイントは？各エンティティには、それを所有するテナントへの直接リンクがあります。

.NET ランドでこれを行うにはどうすればよいでしょうか。エンティティを IoC コンテナーに入れ、実行時にその場でまとめてグロブ化することが提案されていますが、それをリレーショナル データベースにどのようにマッピングすればよいでしょうか。

また、かなり前に Lucene.NET に関するAyende の投稿を読んだことも覚えていますが、これは良さそうですが、現時点では Lucene.NET や nHibernate を使用した経験はありません。(現在、ORM に Linq2Sql を使用する予定ですが、これをサポートするためにそれを変更する必要がある場合は、率直に言って、私は個人的に喜んでいます)。

Ayende からリンクされているこの Castle dev list スレッドを読みましたが、nHibernate には IUserType と呼ばれるものがあり、これが役立つようです。それを適用して、各テナントに適切な IoC を取得することができるのでしょうか? したがって、拡張可能エンティティごとにテナントごとに 1 つの IUserType を作成し、データ自体を SQL Server (最も可能性の高い RDBMS) 内の XML 列に格納します。

最後に、テナントごとのエンティティごとに DB テーブルを動的に変更することに関する 1 つの提案を読みましたが、これはかなり聞こえます... 正直、大変です! つまり、機能する可能性はありますが、これを行う機能をテナント (技術に精通していない可能性がある) に与えることは、それほど素晴らしいアイデアではないように思えます。管理者の従業員のみに制限できると思います...

VBP では、カスタム COM コンポーネントまたはカスタム スクリプトを作成することで、ユーザー定義のアクションを定義できます。

iterativeであるユーザー定義のアクションを作成する必要があります。つまり、アクションに組み込まれた「プロセスファイル」のように、子ステップを反復的に呼び出す必要があります。

これを行う方法がわかりませんし、Google も役に立ちません。

他の開発者やアーキテクトが、特定のサイト向けにアプリケーションの特定の領域をカスタマイズする際のさまざまな方法について読むことに興味があります。顧客が実装した前処理と後処理、同じことを行うイベントへのコールアウト、ビジネス ロジック メソッドのオーバーライドを可能にし、プラグ可能なモジュールによる戦略、データ構成可能なプロセス (ルール エンジン、スクリプトなど) を使用します。

リストはまだまだ続きますが、私は、誰が何を使用したか、これらの各アプローチの長所と短所、および他にどのようなアプローチがあるかを尋ねています。

これは、これらのカスタマイズに対応するために顧客固有のコード ブランチを作成しないことを前提としています。

次のようなコードを使用して、リモート マシンに接続しようとしています。

リモート デスクトップからログオンし、手動でデバッガを起動することで動作するようになりましたが、ログインしたままにしておく必要があります。問題は、リモート マシンにログインしたままにしたくないことです。IDE を介してアタッチした場合と同様に、デバッガーを自動的に起動する方法はありますか?

ASP.NET 3.5 WAP を構築する際、ロジックや UI の一部をどのように「分離」または「カプセル化」しても、必要なときにいつでもサイト全体をダウンさせてしまうという感覚に常に苛立ちます。 1 行のコードを更新します。ASP.NET が "bin" ディレクトリの変更を処理する方法を誤解しているかもしれませんが、「AppDomain がアンロードされるのはなぜですか?」さまざまなグループのメッセージでは、これはまだ避けるべきもののようです。

ASP.NET 3.5 WAP を真にモジュール化して、ロジックとページを「実行中」に追加/更新できるようにするためのガイダンスやフレームワークを持っている人はいますか? System.AddIn を少しググったのですが、WPF アプリケーションに焦点を当てているようです。

ご協力いただきありがとうございます！

ジェームズ・ホワイト

プラグイン作成者がユーザー定義の「エクスポート」機能を提供するために実装できるインターフェースをアプリケーションに定義しようとしています。次のようになります。

ただし、プラグインの作成者には、「パス」がファイル名ではなくフォルダーを表すことを (明示的に、ドキュメントだけでなく) 知らせる必要があります。エクスポート プロセスの一部としてファイルを作成するのは、彼らの責任です。

パスがファイル名ではなくフォルダーであることを強制する最良の方法は何ですか? 私の最善の推測は、文字列の代わりに DirectoryInfo を使用することです。

それは良い解決策ですか、それとも DirectoryInfo インスタンスを渡す際に私が気付いていない落とし穴がありますか?

ソフトウェアを拡張可能に設計する方法、つまり他の人が機能を追加するアドオン/プラグインを作成できるようにする方法について説明するリソースが必要です。

おすすめは何ですか？このテーマについて論じている本はありますか？
短くて要領を得たものを好みます。少しの理論とたくさんの具体例。

私は特定の言語をターゲットにしているわけではありません。どの言語でも実装できるように、核となるアイデアを理解したいと思っています。

同じ理由で、私は他の誰かが構築したフレームワークを使用してそれを行うことを好みません (フレームワークが非常に高レベルではない場合、つまり、あまり隠していない場合を除きます)。現時点では、それを実装するためのさまざまな方法を検討し、実験してください。さらに、フレームワークは通常、主題に関するユーザーの知識を前提としています。

アップデート

OOP について質問したり、クラスの継承を許可したりしているわけではありません。システムにデプロイされるアプリケーションを設計して、デプロイ後にサードパーティのアドオンによって拡張できるようにすることについて話しているのです。

たとえば、Notepad++ には、プラグイン フォルダーに .dll ファイルを配置できるプラグイン アーキテクチャがあり、カラー ピッキングやスニペットの挿入など、そこにはなかった機能がアプリケーションに追加されます。 （幅広い機能）。

VS2010をご覧になった方に質問です。VS2010 でアドインを動作させるために、アドイン開発者が行う必要がある変更はどれくらいですか?