MVC 設計パターンは、より優れたソフトウェア構造とコードの再利用をもたらします

设计

　　模型－视图－控制器（MVC）是Xerox　PARC在八十年代为编程语言Smalltalk－80发明的一种软件设计模式，至今已被广泛使用。最近几年被推荐为Sun公司J2EE平台的设计模式，并且受到越来越多的使用 ColdFusion 和 PHP 的开发者的欢迎。模型－视图－控制器模式是一个有用的工具箱，它有很多好处，但也有一些缺点。

　　MVC如何工作

　　MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。

　　视图

　　视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它们包括Macromedia　Flash和象XHTML，XML/XSL，WML等一些标识语言和Web　services.

　　如何处理应用程序的界面变得越来越有挑战性。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。

　　模型

　　模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。例如它可能用象EJBs和ColdFusion　Components这样的构件对象来处理数据库。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。

　　控制器

コントローラーはユーザー入力を受け入れ、モデルとビューを呼び出してユーザーのニーズを満たします。そのため、Web ページ内のハイパーリンクがクリックされて HTML フォームが送信された場合、コントローラー自体は何も出力したり、処理を実行したりしません。リクエストを受信し、リクエストを処理するためにどのモデル コンポーネントを呼び出すかを決定し、モデル処理によって返されたデータを表示するためにどのビューを使用するかを決定するだけです。

次に、MVC の処理プロセスを要約します。まず、コントローラーがユーザーのリクエストを受け取り、処理のためにどのモデルを呼び出すかを決定します。次に、モデルはビジネス ロジックを使用してユーザーのリクエストを処理し、データを返します。コントローラーは対応するデータを使用します。ビューは、モデルから返されたデータをフォーマットし、プレゼンテーション層を通じてユーザーに表示します。

MVC を使用する理由

ほとんどの Web アプリケーションは、ASP、PHP、または CFML などの手続き型言語を使用して作成されます。データベース クエリなどのデータ レベルのコードと、HTML などのプレゼンテーション レベルのコードが混在しています。経験豊富な開発者はプレゼンテーション層からデータを分離しますが、これは通常は簡単ではなく、慎重な計画と絶え間ない試行錯誤が必要です。 MVC では基本的にそれらを強制的に分離します。 MVC アプリケーションの構築には追加の作業が必要ですが、それによってもたらされる利点は疑いの余地がありません。

まず第一に、複数のビューでモデルを共有できることは、アプリケーションにアクセスする方法がますます増えています。これに対する 1 つの解決策は、ユーザーが Flash インターフェイスを希望するか WAP インターフェイスを希望するかに関係なく、1 つのモデルですべてを処理できる MVC を使用することです。データとビジネス ルールをプレゼンテーション層から分離したため、コードを最大限に再利用できます。

モデルから返されるデータはフォーマットされていないため、同じコンポーネントを異なるインターフェイスで使用できます。たとえば、多くのデータは HTML で表現されますが、Macromedia Flash や WAP で表現されることもあります。モデルには、状態管理およびデータ永続化機能も備わっています。たとえば、セッションベースのショッピング カートや電子商取引プロセスは、Flash Web サイトやワイヤレス ネットワーク アプリケーションによって再利用することもできます。

モデルは自己完結型でコントローラーやビューから切り離されているため、アプリケーションのデータ層やビジネス ルールを簡単に変更できます。データベースを MySQL から Oracle に移行する場合、または RDBMS ベースのデータ ソースを LDAP に変更する場合は、モデルを変更するだけです。モデルを正しく実装すると、データがデータベースからのものであっても LDAP サーバーからのものであっても、ビューにはデータが正しく表示されます。 MVC を使用するアプリケーションの 3 つのコンポーネントは相互に排他的であるため、そのうちの 1 つを変更しても他の 2 つは影響を受けないため、この設計アイデアに基づいて適切な疎結合コンポーネントを構築できます。

私にとって、コントローラーには利点もあります。つまり、コントローラーを使用してさまざまなモデルやビューを接続し、ユーザーのニーズを満たすことができます。このように、コントローラーはアプリケーションを構築するための強力なツールを提供できます。 。 手段。再利用可能なモデルとビューがいくつかある場合、コントローラーはユーザーのニーズに応じて処理するモデルを選択し、ビューを選択して処理結果をユーザーに表示できます。

MVC の欠点

MVC の欠点は、明確に定義されていないため、MVC を完全に理解するのは簡単ではないことです。 MVC の使用には慎重な計画が必要であり、その内部原理が複雑であるため、検討するのに時間がかかります。

MVC をアプリケーションに適用する方法を考えるには、かなりの時間を費やす必要があります。同時に、モデルとビューを厳密に分離する必要があるため、アプリケーションのデバッグも困難になります。すべてのコンポーネントは使用前に徹底的にテストする必要があります。コンポーネントをテストしたら、心配することなく再利用できます。

私の個人的な経験に基づくと、アプリケーションを 3 つのコンポーネントに分割するため、MVC を使用すると、以前よりも多くのファイルを管理する必要があることも意味しますが、これは明らかです。これは私たちの仕事量が増加したように見えるかもしれませんが、それが私たちにもたらすメリットに比べれば、これは何でもないことを覚えておいてください。

MVC は、小規模または中規模のアプリケーションには適していません。それほど大きくないアプリケーションに MVC を適用することに多くの時間を費やすと、通常は利益よりも損失の方が大きくなります。

MVC はソフトウェアを作成するための優れた方法です

MVC デザイン パターンは、コンテンツと表示を分離するなどのいくつかの原則を提唱しています。理解しやすくなります。ただし、モデル、ビュー、コントローラーのコンポーネントを分離したい場合は、アプリケーション、特にアプリケーションのアーキテクチャ面を再考する必要があるかもしれません。 MVC を受け入れる意思があり、MVC がもたらす余分な作業と複雑さに対処できる能力がある場合、MVC は堅牢性、コードの再利用、構造の点でソフトウェアを新しいレベルに引き上げます。