2013-03-10 5 views
6

プロジェクト/ソリューション内に、WebフォームとMVC3.0を組み合わせたMVC 3.0 Webアプリケーションがいくつかあります。MVC WebをSitecoreに移行するためのベストプラクティス

私はsitecoreにはまったく新しく、既存のアプリケーションをSitecoreに移行することに関して、誰かが私の理解を助けてくれますか?

  1. MVC3.0の剃刀ビューをどのようなシナリオに移行する必要がありますか?

  2. MVC3.0をsitecoreに移行する際の重要な点は何ですか?

  3. sitecoreパイプラインに何かを注入する必要がありますか?

  4. サイトリンクで動作するナビゲーションリンクを変更する必要はありますか?

  5. 既存のWebアプリケーションを移行するためのサイトメールのベストプラクティスへのリンクはすべて役に立ちます。

なぜ、ときに我々はサイトコアレンダリングにWebコントロールやかみそりビューを変換する必要があり、私は次のブログに続き、まだ不明。

ありがとうございます。

答えて

9

MVCアプリケーションをSitecoreソリューションに移行する場合、いくつかのオプションがあります。移行するコンポーネントの性質によっては、最適なオプションを選択する必要があります。

私が試してみて、あなたの5具体的な質問に対処します:レイザーは

が、私は質問があるかどうかわからないんだけど見て使用する場合は、「ときカミソリビューを使用するには、」

1または質問が「Sitecore View Renderingを使用するタイミング」である場合は、後者を想定します。

ビューレンダリングは、ビジネスロジックを必要とせず、レンダリングアイテムのみを扱うプレゼンテーションコンポーネントを作成する場合に最適です。あなたのRazorビューにコードを追加することを検討しているなら、おそらくControllerレンダリングがより適切であるか、おそらくmvc.getModelパイプラインをカスタマイズするかどうかを検討するべきでしょう。

2.移行は

サイトコアへのMVCアプリケーションを移行するときあなたを捕まえることが物事の一部を落とし穴。

  • コンポーネントベースのコントローラ - MVCでは1ページあたり1つのコントローラがあります。 SitecoreはControllerRenderingsのコンセプトをサポートしており、ページに複数のコントローラを持つことができます(プライマリとして認識できるルートコントローラは常に1つあります)。
  • アイテムルーティング - Sitecoreには、アイテムパスにマップされるすべてのパスに有効なすべてのルートがキャッチされます。標準的なMVCルートと "アイテムルート"はうまく共存できます。アイテムルートは現在ルートパラメータをサポートしていません(たとえば、アイテムルートに{アクション}や他のパラメータを指定することはできません)。
  • MVC4 - MVC4ため現在のところ公式サポート(これは長い間成り立たないだろう - しかし、その間にhttp://herskind.co.uk/blog/2012/10/sitecore-66-mvc4を見て)
  • エリア - 現在の領域が完全にサポートされていません。
  • 使用するレンダリングタイプと、既存の機能をコンポーネントに変換するタイミングを知らない。

3.パイプラインのカスタマイズ

あなたはサイトコアのパイプラインをカスタマイズすることを強要されません。マイグレーションストーリーのコンテキストでパイプラインを変更すると便利ないくつかの例があります。最近私がSitecoreユーザーグループで話した1つの例は、ASP.Net MVCアプリケーションをSitecoreプレースホルダに注入するをグローバルに(mvc.resultExecutingパイプラインを通じて)追加することでした。私の例では、MVC Music Storeをプレースホルダに挿入し、Sitecoreコントロールウィンドウドレッシング(ヘッダー/フッター/メニュー)を持っていました。このようにして、私は既存のMVCアプリケーションをSitecoreに持っていくことができます。ナビゲーション・エンドポイントはサイトコアアイテムの経路である場合

4.ナビゲーションは、あなたが適切なリンクを生成するために、サイトコアのLinkManagerを使用する必要があります(Webサイト上の項目へのパスをデュポン社)

をリンクします。エンドポイントが標準のMVCルートの場合は、RouteLinkActionLinkはうまく動作します。

具体的な例がないと、答えは「多分」となるでしょう。

5.ベストプラクティス移行のブログ記事

私は、サイトコアMVCの移行のベストプラクティスを扱うすべてのブログ投稿や記事を認識していませんよ。完全なMVCサポートはSitecoreへの最近の追加であり、まだ始まりから終わりまでこの旅を多く見ていないことに注意してください。

なぜ、いつサイトコアレンダリングに

を変換するためにあなたはまだ、なぜあなたはサイトコアレンダリングにコントロールし、カミソリの景色を変換するだろうというときについて混乱している旨のご質問を終了します。 Sitecoreレンダリングの候補となるものがいくつかあります。

  • これは多くのページで再利用できるコンポーネントです。
  • Sitecoreユーザーがコンポーネントをページに追加できるようにする必要があります。 (ページエディタと思う)
  • Sitecoreのコンポーネントレベルのキャッシュを活用したいと思っています。
  • Sitecoreセキュリティを活用して、コンポーネントを使用/参照できるユーザーを制限したいとします。
  • パーソナライゼーション、ルール、またはMVTを使用してコンポーネントを制御する必要があります。ここでのMVCの文脈では

サイトコアのレンダリングに何かを変換する権利ではないかもしれないいくつかの指標である:

  • それは、ルーティングとルートのパラメータに大きく依存しています。

私はこの答えの点の多くが上に展開することができ、私はこれには明確なルールがないことを知っている確信している - しかし、私はこの答えは

...混乱のいくつかを明確に役立ちます願っています
+1

+1 - 「ベストプラクティス」か、試してみると最初のブログ投稿であるのかどうかは不明ですが、ここではMVC Music StoreのチュートリアルサイトをSitecore MVCに変換する方法についての記事を掲載しています。 http://www.sitecore.net/Community/Best-Practice-Blogs/Chris-van-de-Steeg/Posts/2012/08/MVC-Controller-Renderings-for-Sitecore.aspx –

+0

I Chrisのブログ記事それがSitecore MVCのさまざまな側面をどのように使うことができるかを示す良い例だと思います。しかし、シナリオが "MVC Music Store"アプリケーションで始まっていて、それをSitecoreソリューションに組み込みたいのであれば、おそらくSitecoreでそれを再構成するための部分だけを引き出すことはできません。一部のコンポーネントは、他のコンポーネントよりもSitecoreレンダリングに適しています。 – herskinduk

関連する問題