Blog

.NETプラットフォームと進化し続けるCMS市場の最近の改善により、機能豊富なWebサイトの作成に関するガイダンスがいつでも利用できます。しかし、複雑なチュートリアルを行う時間がなく、最新のシンプルで管理しやすいサイトが必要な場合はどうでしょうか。

.NET Core 3.xのリリース、 ASP.NET Core MVCの進歩、Blazorプレビューの登場により、.NETコミュニティには多くの興奮があります。これらの改善は素晴らしいものですが、MVCの堅牢性とBlazorの新しさにより、一部のプロジェクトは複雑すぎると感じる可能性があります。開発の複雑さに加えて、CMSのインストールとアップグレードを考慮すると、プロジェクトに余分なオーバーヘッドが追加される可能性があります。次の記事では、ASP.NET CoreRazorページとサービスとしてのコンテンツ（CaaS）がオーバーヘッドと複雑さの防止にどのように役立つかについて説明します。 。 あなたが私のようにKISSの原則を強く信じているのであれば、この記事があなたの.NET開発がばかげた単純なものになり得ることを示していることを願っています！

なぜレイザーページ？

わかりやすい構造

ASP.NET Core Razor Pagesは、プロジェクト構造に対してページに焦点を当てたアプローチを採用しています。ページのビューとそのPageModel（ビューに関連するロジック）を「Pages」ディレクトリに配置します。コンテンツをモデル化し、その大部分が「ページ」の概念に基づいて構成されていることを確認した場合、RazorPagesはプロジェクトに最適なフレームワークである可能性があります。

たとえば、私のサンプルのコーヒーショッププロジェクトには、コーヒーとカフェに関する基本的な情報ページがたくさんあります。 「カフェ」ページに変更を加えたい場合は、 〜/ Pages / Cafes / Index.cshtmlに移動してビューを編集するか、 〜/ Pages / Cafes / Index.cshtml /Index.cshtml.csに移動して論理。

この単一責任スタイルの構造により、ページは「Pages」フォルダーにあるため、特定のページのコードを見つけるのが難しくなります。

親しみやすさ

Webフォームを使用したことがある場合は、同じ場所に配置されるレイアウトとロジックに関する上記の説明は非常によく知られているはずです。 Razor Pagesは、その構造からWebフォームの後継と見なされることもありますが、.NETCoreの最新機能が付属しています。したがって、.NET Core機能を使用するためにWebフォームからMVCへの移行を恐れているのであれば、RazorPagesは歓迎される体験になると確信しています。

オプション

ルーティングは非常に混乱したり、エラーが発生したりする可能性があります。そうは言っても、MVCのそれほど単純ではないコントローラー->アクション->ビューアプローチを使用する代わりに、Razor Pagesプロジェクトのデフォルトのルーティングでは、プロジェクト内のページの場所を使用してURLを決定します。

たとえば、「mysite.com/Articles」へのリクエストは〜Pages / Articles / Index.cshtmlとそれぞれの.csファイルによって処理され、「mysite.com/Articles/Detail」へのリクエストはPagesによって処理されます。 /Articles/Detail.cshtmlとその.csファイル。

この動作はルーティングを簡素化するのに役立ちますが、カスタムルートの使用を妨げることはありません。たとえば、私のサンプルプロジェクトでは、特定の記事を返し、訪問者に実用的なアドレスを提示するために、@ pageディレクティブを使用して記事のURLにセグメントを追加することを選択しました。

Articles / Detail.cshtmlビューでは、ディレクティブ@page“ {UrlPattern}”が使用されます。

このUrlPattern値は、ヘッドレスCMSのAPIからコンテンツを返すためにページのロジックで使用されます。 Content-as-a-Service / headless CMSの選択については、この記事の後半で説明しますが、今のところ、 @ pageディレクティブを使用すると、「http：//」などのURLにセグメントを追加できますのでご安心ください。 mysite.com/Articles/Detail/コーヒー加工・技術。」

ページディレクティブに加えて、Razor Pagesプロジェクトは、StartupクラスのサービスコレクションでAddRazorPagesおよびAddRazorPagesOptionsを使用できます。 これにより、RazorPagesルーティングに関するMicrosoftの公式ドキュメントに記載されているルーティングの可能性が広がります。これを紹介するために、ホームページにカスタムルーティングを使用しました。ホームページを自分のサイトの他のページと同様のサブフォルダーに整理したかったのですが、URLに「/ Home」を含めたくありませんでした。これは複雑なルーティングシナリオではありませんが、このアプローチによってどのように柔軟なルーティングが可能になるかがわかります。

これまでページ中心の構造に焦点を当ててきましたが、それはあなたのプロジェクトがページに限定されているという意味ではありません。ページとは異なる機能、または複数のページで再利用できる機能は、ViewComponentsを使用して実装できます。たとえば、私のプロジェクトでは、連絡先情報を表示するためのロジックとビューを含むComponentsフォルダーをPages内に作成しました。このコンポーネントをサイトのフッターで使用するには、共有レイアウトで@await Component.InvokeAsync('Contact')

これは追加しますが 特定のページに直接関連していないPages内のフォルダーの場合、このコンポーネントはコンテンツをページにレンダリングする役割を果たします。したがって、この場所に配置することは依然として賢明なようです。

これらは、Razor Pagesを使用して、開発者が.NET Coreで提供される最新の機能の多くの利点を享受しながら、プロジェクトを可能な限りシンプルに保つ方法のいくつかの例です。そうは言っても、コードを書くことは、素晴らしいWebサイトを作成するために必要な労力のほんの一部にすぎません。 「シンプルさ」のテーマをプロジェクトのコンテンツ管理にどのように拡張できますか？

なぜCaaSなのか？

手始めに、「CaaS」とは何ですか？ Content as a Serviceは、Software as a Serviceコンテンツ管理システムでコンテンツを作成し、APIを使用してそのコンテンツを複数のチャネルに配信するためのアプローチです。 「それはヘッドレスCMSのように聞こえます...」とお考えかもしれません。コンテンツ作成へのCaaSアプローチは、ヘッドレスCMSを活用しますが、編集者にCMSを提供し、開発者にAPIを提供することに加えて、さまざまなサービス、バンドル、またはオファリングも含みます。この記事のために、経験に合っている場合は、「ヘッドレスCMS」の代わりに「CaaS」を使用できます。

CMSのメンテナンスなし

オンプレミスのCMSを管理したことがある場合、またはCMSの展開と保守に携わったことがある場合は、かなりのオーバーヘッドが発生することをご存知でしょう。インストール、メンテナンスウィンドウの管理、アップグレードの実行、バグ修正の適用、インフラストラクチャのアップグレード...リストはどんどん増えていきます。これらのタスクは、開発とコンテンツ作成から時間がかかります。 Content-as-a-Serviceオファリングを使用すると、ベンダーがCMSとインフラストラクチャのメンテナンスを処理し、開発に集中できるようになります。

オムニチャネル

プロジェクトをシンプルにしようとしていますが、世界はシンプルな場所ではありません。お客様には複雑なニーズがあります。 2020年以降、顧客は自分のコンテンツがWebサイト、モバイルアプリケーション、音声アシスタント、およびその他のチャネルで利用できることを期待するようになります。プラットフォームに依存せず、APIを介して任意のチャネルに配信できるシステムまたはサービスでコンテンツを作成することにより、これらの他のメディアへのプロジェクトの将来の拡張が可能であることを保証します。

構造化されたコンテンツ

オムニチャネルのメリットに加えて、CaaSを使用すると、コンテンツが構造化されていることを確認できるため、開発が容易になります。 CaaS製品がAPI応答をJSONまたはXML形式で送信することは一般的な方法です。これにより、APIから返されるコンテンツがプロジェクト全体で予測可能で一貫性のあるものになるため、開発プロセスが合理化されます。開発の初期段階で適切なコンテンツモデリングを行っていれば、CaaSAPIからの応答を使用するときに推測を行う必要はありません。均一で構造化されたコンテンツ配信で当て推量を最小限に抑えることで、開発プロセスが確実にスムーズになります。

なぜケンティココンテント？

サンプルプロジェクトでは、CaaSオファリングとしてKenticoKontentを使用することを選択しました。なぜCaaSにリストされているすべての要件を満たすことに加えて？上記のセクションでは、 KenticoKontentのオープンソース.NETSDKとサポートツールにより、開発エクスペリエンスがさらに向上しています。

.NET SDK

2020年には、クリーンなAPIを持つことは、快適な開発者エクスペリエンスの頂点ではありません。 APIサービスを活用している多くの開発者は、基本のAPIドキュメント自体とほぼ同じ速さでSDKドキュメントに飛び込むと私は主張します。これを念頭に置いて、KenticoKontentの.NETSDKには、適切な命名規則、 広範なドキュメント、およびSDKのセットアップとコンテンツのクエリを簡単にする依存性注入のサポートがあります。たとえば、依存性注入と強い型付けに関連するコードを除いて、KenticoKontentから「AboutUs」アイテムを取得するための私の呼び出しは1行のコードです。

このコードは、Kentico Kontentユーザーインターフェイスで作成した「AboutUs」コンテンツアイテムに関するすべての詳細を含む構造化されたJSON応答を返し、それをAboutUsモデルにキャストします。

SDKで依存性注入を使用するようにアプリケーションを設定するには、appsettings.jsonファイルの標準構成を使用するServices.csファイルの単一のサービス登録で実行できます。

 public class Startup{ public Startup(IConfiguration configuration) { Configuration = configuration; } public IConfigurationRoot Configuration { get; } public void ConfigureServices(IServiceCollection services) { services.AddDeliveryClient(Configuration); }}

 { 'DeliveryOptions': { 'ProjectId': '' }}

上記の例では最小限のセットアップに焦点を当てていますが、心配しないでください。プロジェクトにさらに高度な機能が必要な場合、Kentico Kontent .NET SDKには多くの機能とオプションがあり、需要や複雑さの増大に合わせてプロジェクトを快適に拡張できます。

モデルジェネレーター

Razor PagesのようなModel-View-ViewModelデザインパターンを使用する場合、モデルの作成と更新は、特にコンテンツ作成者やプロジェクトマネージャーがコンテンツの構造や要件を変更する場合、かなりの量の先行作業と継続的な作業になる可能性があります。これを説明するために、Kentico Kontentには、プロジェクトの強く型付けされたモデルを自動的に生成するオープンソースツールがあります。 IntelliSenseの強く型付けされたモデルに依存し、モデルを手動で編集するのが嫌いで、CLIツールを使用してこの面倒なタスクを実行してもかまわない場合は、KenticoKontent が.NET用のKontentモデルジェネレーターを提供したことを気に入るはずです。プロジェクト。

開発者だけでなく

開発特典に加えて、ヘッドレスCMSは編集者とそのマネージャーにもメリットをもたらします。コンテンツ作成機能に興味がある場合は、 このページをチェックするか、自分で試してみてください。マニュアルは必要ありません！

概要

この記事では、ASP.NET Core Razor Pagesのどの側面が、構造と機能セットの両方でシンプルでありながら最新のWebサイトを作成するための優れたフレームワークになるかについて説明しました。また、RazorPagesをKenticoKontentなどのCaaSオファリングと組み合わせることで、開発のオーバーヘッドをさらに削減する方法についても説明しました。 私のサンプルプロジェクトのデモンストレーションが、2020年以降にそれをシンプルに保つ方法を示したことを願っています！