Web用のMVC以外のデザインパターンはありますか？

MVC以外にWebのデザインパターンはありますか？

次のようなデザインパターンがあることを知っています：Registry、Observer、Factory、ActiveRecord、...、MVCその他のデザインパターンとフォルダー構造のセット。

MVCは他のデザインパターンのセットであるようなデザインパターンはありますか？

編集：私のプログラミング言語はPHPです。

ソフトウェア開発にはさまざまなパターンがあります。MVP、MVVM、MVCなどはよく知られたものの一部です。ただし、解決または使用しようとしている特定の問題または技術を定義する必要があります。

これらのパターンはそれぞれ、いくつかの特定の問題を解決するのに適しています。たとえば、MVP（モデルビュープレゼンター）パターンは、ASP.NET WebForms開発で懸念の分離を導入するのに役立ちます。これは、Webページのデータを収集、表示、および保存する責任を、モデルオブジェクト、ビューオブジェクト、プレゼンターオブジェクトの各オブジェクトに分割することで構成されます。

デザインパターンの最も有名な一般的な料理本は、ギャングオブフォー（GoF）デザインパターンです。

編集： .NETプラットフォームでのデザインパターンの実装に興味があると思います

数週間前に出会った素敵なパターンはMOVEです。MVCのように少し洗練されていますが、同じ原理に基づいています。MVCの欠点の1つは、コントローラーが非常に大きくなる可能性があることです。MOVEパターンを使用して、この問題を少し処理します。

他の名前が付けられた他のパターンも良い選択肢です。

最初に確立することは、フレームワークやMVC（または他のデザインパターン）が有益かどうかを判断するために、正確に何をする必要があるかです。

通常、一般的なプログラミング要件（データベースの相互作用、フォームの作成と検証、ユーザー認証など）に対するソリューションを提供しながら、フレームワークは開発用の一貫したプラットフォームを提供します。

PHPの場合、少なくともMVC / HMVCのデザインパターンは、利用可能なメインストリームフレームワーク（Zend、CakePHP、CodeIgniterなど）を支配する傾向がありますが、使用できるデザインパターンは多数あります。

MVCは、データモデリングと処理ロジックをビュー/プレゼンテーションレイヤー（堅牢でスケーラブルなアプリケーションを作成するために望ましいと考えられるもの）を分離する確立され理解された方法を提供するため、非常に人気があります。

MVC、MVP、MVVM、およびその他のMV xパターンが（少なくとも原則として）すべて同じ「デザインパターン」であることに注意してください（そして@MarYuvenovのコメントへのコメントで@Marjan Venemaによって表されたように）。

通常、異なるデザインパターンはすべて（多くの場合微妙に）異なる目的に使用され、特定の言語を念頭に置いて開発された場合もあります。しかし、真の「設計パターン」はプログラミングの難しいルールではなく、実際にはプログラムの実装と設計要件および論理関数を哲学的/概念的に理解したものです。

さまざまなプログラミングプリンシパルとベストプラクティスについて調べるには、調査が最善の方法です。始めるためのウィキペディアのリンクを次に示します。

• デザインパターン
• 契約による設計
• ソフトウェア設計パターン
• 建築パターン
• 相互作用設計パターン

実際には、独自の「パターン」を実装することを妨げるものは何もありません、IMOを実行することで学ぶのが最良の方法です。

プログラミングの概念とベストプラクティスの一部を理解したら、それらを使用して独自のシステムを構築し、直面している特定の問題を解決し、確立された「パターン」に準拠しているかどうかにかかわらず、ニーズを満たすことができます。

解決すべき特定の問題がない場合は、一般的なフレームワークのいずれかを学習するのが最善の策です。

最も有名な例の1つは、MVVMデザインパターンを使用するjavascriptフレームワークであるKnockout.jsです。MVCフレームワークBackbone.jsとKnockout.jsを比較したスタックオーバーフローに関するすばらしい記事がここにあります。

副次的な注意点は、MVVM設計パターンは、Martin FowlerのPM設計パターンの特殊化としてMicrosoftから生まれたことです。MVVMは、WPFアプリケーションで広く使用されています。

ElYusubovが指摘したように、比較的主流の例を探しているのであれば、ASP.Netフレームワークには長い間MVPとMVVMのパターンがあります。MVCとMVVMの主な違いの1つは、エンティティの更新方法です。MVCは、Webアプリケーションの従来のステートレスまたはセミステートレスのアプローチにより適しています。ASP.Netフレームワークは、フォームに埋め込まれた状態を維持することにより（各リクエストで復元できるようにする）、この問題を回避しようとしました。

HTML5では、アプリケーションのJavaScriptがますます重くなり、その状態の多くはクライアント上にあります。これはMVVMフレームワークの復活につながる可能性があり、Knockout JSはその一例です。

野生のほとんどのパターンはMVC、またはMVCのフレーバーです。結局のところ、データ（モデル）、表現（ビュー）、およびそれとの相互作用（コントローラー）を分割することは理にかなっています。80年代に設立されたMVCを見ると、Webフレームワークになることを意図したものではなかったことがわかります。したがって、私はそれがウェブで非常に重荷であることがわかりました。

他のよく知られたパターンは、サービス指向アーキテクチャ（SOA）です。その上に構築された最新のアプローチは、サーバーでMVC（またはフレーバー）を使用し、使用できるサービスを公開することです。クライアント側には、他のMVCスタイルのアプリケーション、たとえばHTML5およびJavaScriptを使用したWebアプリケーション（TwitterやLinked Inなど）があります。クライアントアプリケーションは、サーバー側サービス（サーバーの「ビュー」）をモデルとして使用します。私見、これは最先端であり、おそらくサーバー側だけMVCを脇に押します。

私は個人的にはResource Methods Representationのアイデアを使用したものの実装を検討していますが、この段階ではほとんど何よりも単なる実験にすぎません。MVC（短命の要求/応答セッションとは対照的に、単一のコンピューターで実行される長命のアプリケーションを対象としています）よりも優れたHTTP要求/応答をモデル化するという点でいくつかの魅力的なポイントがあります。ただし、GET、POST、PUT、DELETEなどを処理するメソッドをリソースに追加すると、リソースがフロントエンドに結合されるという欠点があります。私はそれを別のレイヤーに分離するつもりだと思っています。

MVC以外には1000を超える方法があります。一部はMVCに似ており、まったく異なるものもあります

例えば ​​：

1. モデルテンプレートビュー-MTV
2. モデルビュープレゼンター-MVP
3. 階層モデル-ビュー-コントローラーHMVC
4. モデルビューViewModel- MVVM

等