誰もが MVC について話している今、ビジネス ルールが取り上げられていないことに気付きました。3 層アーキテクチャの昔、ビジネス ルールは中間層にありました。それらは新しい MVC のどこに分類されますか?
10796 次
9 に答える
39
MVCアドレス「ビジネスルール」が表示されない理由は、MVC全体がプレゼンテーションパターンであるためです。これは、アプリケーションを構造化する方法に焦点を当てています。たとえば、モデルはプレゼンテーションモデルと考えることができます。ビューがレンダリングするアプリケーションのモデル。
ただし、プレゼンテーションモデルを作成するには、通常、すべてのビジネスロジックが存在するドメインモデルに移動する必要があります。その時点で、MVCはそのコードが物理的にどこに存在するかを指示しません。別の層にありますか？MVCは気にしません。
于 2008-10-17T16:42:19.830 に答える
18
一見すると、それらはモデルに属していると思います。ウィキペディアのMVC エントリは、「MVC では、モデルはアプリケーションの情報 (データ) と、データの操作に使用されるビジネス ルールを表します」と同意しているようです。結局のところ、「ビジネス ルール」とは、入力/出力関連のロジックとは対照的に、アプリケーションが関与するドメインをエンコードする機能的なアルゴリズムとロジックを意味します。これらの中核となるビジネス関連のロジックは、ユーザーに表示されるもの (ビューのドメイン) またはユーザー入力 (主にコントローラーによって受信される) に基づいて、変更されないか、変更されるべきではありません。
私の経験では、この種の質問をすることは、ソフトウェア開発プロセス中に非常に明らかになりました.一部の人々は「ビジネスルール」と見なしていたが、実際には別のものであることが判明した多くのことを発見しました. 真のビジネス ルールでない場合は、モデルに属していない可能性があります。
于 2008-10-17T13:15:57.017 に答える
12
ビジネス ルールは常にモデル内に存在します。モデルは、まったく異なる UI で再利用できるビットです。ビューは明らかに UI の選択に完全に依存しており、コントローラーはモデルからデータを取得し、それをレンダリングするようにビューに指示する必要があります。
ビジネス ロジックをビューに入れることは、構造をプレゼンテーションに結びつけるため、良くありません。
ビジネス ロジックをコントローラーに配置することは、ビジネス ドメインをモデルによって永続化されたデータとコントローラー内のルールの間で分割するため、良くありません。
于 2008-10-17T13:22:11.387 に答える
5
ウィキペディアの記事からの引用：
MVC は、ビューが実際の HTML ページであり、コントローラーが動的データを収集して HTML 内のコンテンツを生成するコードである Web アプリケーションでよく見られます。最後に、モデルは、通常はデータベースまたは XML ノードに格納されている実際のコンテンツと、ユーザー アクションに基づいてそのコンテンツを変換するビジネス ルールによって表されます。
于 2008-10-17T13:15:05.723 に答える
4
MVC と Ntier を混在できない理由はありますか? 私たちのアプリケーションはまさにそれを行います。当社のコントローラーはデータ検証に使用され、どのビジネスレイヤー呼び出しを行うかを決定します。
OurApp.Web - Asp.net MVC プロジェクト
OurApp.Business - ビジネス層ライブラリ
OurApp.DataAccess - データ層ライブラリ
OurApp.Entities - 基本的にすべての層で共有されるすべての「モデル」
于 2008-10-17T13:20:22.170 に答える
2
ビジネス ルールは、コントローラーではなく、モデル内にある必要があります。コントローラーとビューはプレゼンテーション層の一部です。
モデルは、ドメインのエンティティと機能を表します..
コントローラーは、ユーザーの入力と要求を受け取り、モデル内/モデルに対してアクションを実行し、それをプレゼンテーション層のビューにマッピングするための単なるマネージャーです。コントローラーは単なるメディエーターではなく、ビューまたはコントローラーがモデルに作用する場合があります。
于 2009-10-01T09:03:58.667 に答える
1
これは以前に投稿された質問ですが、ルール リポジトリがアプリケーションのどの部分からも完全に独立していることを好みます。ビジネス層の複数の実装である複数のアプリケーションが、ビジネス ルール リポジトリの静的レンダリングにアクセスできる必要があります。このような単純な分離の決定により、デスクトップから Web への移行が簡単になります。
私のアーキテクチャでは、ビュー -> モデル -> コントローラ -> ビジネス層 -> ルール リポジトリです。つまり、コントローラは、ビジネス層/層によって提示される粗いデータにアクセスし、それを提示可能な形式にマッサージするモデルにフィードします。 view はそれを受動的に表示します。あらゆるプレゼンテーション形式で再利用可能なビジネス層には、明示的なルールと、暗黙的なルールを持つサブシステムへのアクセスがあります。設計上、各コンポーネントはその上のコンポーネントの詳細を認識しません。
于 2012-08-11T05:56:56.893 に答える
0
問題は定義の問題だと思います。必要な順序で画面を表示するためのロジックはコントローラーの問題であり、ルール エンジンを使用して順序とユーザーからの入力が必要なものを決定するプロジェクトを見てきました。これは、私見のビジネスルールと同じではありません。
于 2012-05-05T16:49:26.717 に答える
-7
モデルではなく、コントローラー内に存在するビジネスルールが間違っています...
于 2009-06-23T14:48:59.187 に答える