5

私は解決するのが非常に難しい問題を抱えています、そして私はたくさん考えて検索し、そして私が言及する1つの結論に行き着きました。問題は、共通の機能に基づいてWebサイトを作成したいクライアントがいることです。これをモジュールと呼びましょう。モジュールをプラグインするための優れたアイデアである、MVC Contrib Portable Areasを使用することを考えましたが、大きな問題です。彼が望む新しいサイトに実装されるブログモジュールを作成したとしましょう。現在、一部のユーザーには、各記事に写真のギャラリーを追加したり、各記事の参照のリストを追加したりする必要があるなど、固有の要件があります。これは、作業するサイトが1つしかない通常の状況では簡単なので、必要なのは

  • 外部キーを持つ新しいギャラリーテーブルをブログテーブルに追加します。
  • Linq2SQlコードを再生成し、モデルを更新します。
  • ビューの作成、編集、削除に新しいフォーム要素を追加します。
  • コントローラにロジックを追加します。

しかし、私の状況では、2つの理由で複雑で時間が面倒です

  • 新しい機能が優れていて、クライアントがそれをすべてのサイトに実装することを決定した場合は、サイトごとに作業を繰り返す必要があります。
  • 機能がユニークである場合、それは将来私にとって矛盾を生み出すでしょう

そのため、問題を解決するための最初のステップとして、ポータブルエリアを使用して各モジュールのアドオンを作成しました。これにより、新しいモジュールまたはアドオンごとに1つのDLLをドラッグすることで、作業が確実に簡単になりますが、ここで少し問題があります。

  • 新しいモジュールまたはアドインはDLLであるため、管理パネルでこのような機能を作成して、新しいアドオンをインストールしたり、新しく追加されたモジュール/アドオンを見つけて新しいDLLをメインアプリケーションにドラッグしたりするにはどうすればよいですか。
  • DBの更新、新しいルートなど、ポータブルエリア内にインストール手順を作成するためのベストプラクティスは何ですか。

ここで、モジュールアドオンに固有の最大の問題について説明します。ArticleGalleryアドオンを取り戻しましょう。上記のロジックに従ってポータブル領域として作成すると、モジュールで機能を作成する方が簡単になります。インストールされているすべてのアドオンをループしてCRUDビューに一覧表示するコードですが、アドオンを分離し、上記の理由でメインモジュールコードを手動で更新したくないため、新しいアドオンのCRUD操作を実行する方法はありません。外部キー関係がないため、メインモジュールと同期します。また、上記で述べたように、オプションである可能性があるため、次の解決策を考えました。より良い解決策があることを願っています。

インストールプロセスの最初に、Gallery Addonのテーブルを作成しますが、外部キーリレーションを作成する代わりに、手動の外部キーを作成します。これは、を使用してレコードを作成するときに、メインモジュールコントローラーで一意のIDを生成することによって入力されます。次のコードをViewDataに保存し、新しいレコードを作成するときにアドオンコントローラーに渡します。

private  string GenerateId()
 {
  long i = 1;
  foreach (byte b in Guid.NewGuid().ToByteArray())
  {
   i *= ((int)b + 1);
  }
  return string.Format("{0:x}", i - DateTime.Now.Ticks);
 }
ViewData["FK"] = GenerateId();

しかし、ここに私の懸念があります

  • この方法は実行可能ですか、それとも単なる愚かです。
  • この手法は、真にユニークなキーを生成します。

私の質問が足りない場合は非常に申し訳ありませんが、これは質問するのに最適な場所であり、多くの人がそのような機能を持ちたいと思っており、誰かが私に答えてくれることを願っています

4

1 に答える 1

2

いい質問だと思います。しばらく前に、プラグインをサポートしたかったMVC1を使用してCMSプロジェクトに取り組み始めました。管理者が新しいプラグインアセンブリをbinフォルダーにドロップできるように機能させ、次のアプリの起動時に、すべてのアセンブリでIPlugin（またはその他）をスキャンしてロードしました。部分ビューをプラグインアセンブリに埋め込んだので、すべて自己完結型でした。各プラグインは、ページに配置されたときに一意の識別子が与えられ、プラグインのコントローラーは、そのIDを使用して独自のテーブル（リポジトリ）にデータを照会する方法を知っていました。メインアプリケーションはプラグインのスキーマについて何も知りませんでした。

ここでの唯一の違いは、同じデータベースで複数のWebサイトを実行しているように聞こえ、各Webサイトに必要なプラグインのインスタンスを区別する必要があることです。どこかに、それがどのWebサイトであるかを示すキーがあり、それを外部キーを介して使用して、ユーザーが表示しているページのそのWebサイトのプラグインのみを選択できると思います。

これが答えかどうかはわかりませんが、私はただ大声で考えているだけです。うまくいけば、それは議論を少し助けるでしょう。

編集：プラグインを自動的にロードするために、IModuleのアセンブリをスキャンするNInjectの機能を使用しました。私のIPluginはから継承しNinject.Modules.INinjectModule、すべてのプラグインはIPluginインターフェースを実装します。次に、アプリの起動時に、次の行があります。

kernel.Load( "*.Plugin.dll" );

ここで、kernelはNinject.IKernelであり、その行はそのファイルパターンに一致するアセンブリをスキャンするため、Weather.Plugin.dllのようなアセンブリをドロップできます。

于 2010-07-16T16:32:47.810 に答える