タグ付けされた質問 「mvc」

MVC(Model-View-Controller)は、関心事の分離を強制するソフトウェアアーキテクチャパターンです。

2
REST APIエラー応答モデルとエラーコードシステムを作成する最良の方法は何ですか?
私のREST実装は、次の構造を持つJSONでエラーを返します。 { "http_response":400, "dev_message":"There is a problem", "message_for_user":"Bad request", "some_internal_error_code":12345 } プロパティ(dev_message、message_for_user、some_internal_error_code)に必要な値を渡し、それらを返すことができる特別な応答モデルを作成することをお勧めします。コードでは、これは次のようになります。 $responseModel = new MyResponseModel(400,"Something is bad", etc...); このモデルはどのように見えるべきですか?メソッドを実装する必要があります。たとえば、テキスト情報のみを渡すsuccessResponse()で、コードはデフォルトで200になりますか?これにこだわっています。これは私の質問の最初の部分です。このモデルを実装する必要がありますか、これは良い練習ですか?今のところ、コードから直接配列を返すだけだからです。 2番目の部分は、エラーコードシステムについてです。エラーコードについては、ドキュメントで説明します。しかし、私が遭遇している問題はコードにあります。エラーコードを管理する最良の方法は何ですか?それらをモデル内に記述する必要がありますか?または、これを処理するための別のサービスを作成する方が良いでしょうか? 更新1 応答用のモデルクラスを実装しました。これはGregの答えと似ていますが、同じロジックですが、さらに、モデルに記述されたエラーをハードコーディングしました。ここでは、次のようになります。 class ErrorResponse { const SOME_ENTITY_NOT_FOUND = 100; protected $errorMessages = [100 => ["error_message" => "That entity doesn't exist!"]]; ...some code... } なぜこれをしたのですか?そして何のために? コードでは格好いいです: return new ErrorResponse(ErrorResponse::SOME_ENTITY_NOT_FOUND ); …
15 php  mvc  rest  api 

8
Web用のMVC以外のデザインパターンはありますか?
MVC以外にWebのデザインパターンはありますか? 次のようなデザインパターンがあることを知っています:Registry、Observer、Factory、ActiveRecord、...、MVCその他のデザインパターンとフォルダー構造のセット。 MVCは他のデザインパターンのセットであるようなデザインパターンはありますか? 編集:私のプログラミング言語はPHPです。

4
MVCでは、複数のビューで同じコントローラーを使用できますか、または1つのビューで1つの一意のコントローラーを使用する必要がありますか?
MVCを中心としたプロジェクトのアーキテクチャを設計しているときに質問があります。(これはC ++ / Marmalade SDKプロジェクトです。特定のMVCフレームワークは使用していません。作成しています。) いくつかの記事(元のSteve Burbek記事など)で、「MVCトライアド」という概念を読み続けています。初めて読んだとき、アプリケーションは「MVCトライアド」ユニット(想定している各UIピースに1つ)を中心に構築されているように見えましたが、これはかなり柔軟性に欠け、MVCの使用が意図されていなかったと思います。次に、この問題をさらに調査すると、コントローラーとビューの密結合の例、つまり1対1の関係が見つかりました-TextEditViewにはTextEditControllerがあります。 しかし、プロジェクトに戻ると、(AddElementControllerのような「論理ユニット」による)1つのコントローラーと、その特定のコントローラーの複数のビューがあると便利です。 私は、何らかのタブUIが必要なAddElementControllerのようなものについて明確に考えています。AddElementTabViewとタブ用の複数のAddImageView、AddSoundViewなどを持つAddElementControllerが必要ですか?または、タブビューごとに異なる「サブコントローラー」が必要ですか? 要約すると、MVCパターン(このフレームワークのXフレームワーク固有の理解/実装ではありません)に関して、コントローラーに複数のビューがあるのは正しいですか、または各ビューに特定のコントローラーが必要ですか? また、いくつかの状態情報をコントローラーに保持するのは正しいですか、それともステートレスである必要があります(つまり、状態を非ドメイン状態モデルに配置する必要があるということですか)。 事前にすべてに感謝します。

3
MVC:モデルとサービスの違いは何ですか?
一部のフレームワークではロジック層が「モデル」と呼ばれるのに対し、一部のフレームワークでは「サービス」と呼ばれるのはなぜですか。それらは互いに異なるのですか、それとも命名規則によってのみ異なるのですか? 更新1 私が求めている理由は、古典的なMVCフレームワークであるZend Frameworkでは、誰もがモデルの概念を使用しているためです。今、私はAngularJSを学んでいますが、Modelという言葉は消えて、serviceという言葉に置き換えられたようです。 私が気づいたのは、サービスは何度も何度も再利用できるシングルトンに似ていることです(例:RESTクライアント)。一方、モデルはMVCパターンのコントローラーからのデータ操作により関連しています。
15 mvc  model  service 

4
適切なModel-View -_____デザイン
モデルビューコントローラー、モデルビュープレゼンター、モデルビューViewModelなどについて読んでいますが、一般的に、基本的な概念は非常に理解しやすいようです。可能。デザインチョコレートにロジックピーナッツバターは含まれていません。クール、私はそれが好きです。 問題は、その3番目の部分についてはまだ少し曖昧だということです...モデルまたはビューではありません。誰もがそれを何と呼ぶべきか、何をすべきか、何が適切で、何が間違っているのか、自分の考えを持っているようです...それはプレゼンターの仕事だからです。 私はとりとめのないです。 それらの違いを誰かに説明するように頼むのではなく、すでに何度も行われているので(私は知っています;数え切れないほど多くの記事を読んでいます)-私は私は自分でモデルを作った少数のプログラマーです。 そうは言っても、このデザインをどのように分類しますか?そしておそらくもっと重要なことですが、これについて明らかに悪いことはありますか?確かに、これが本当に堅実な設計であれば、私は良いことをしていると聞きたいと思いますが、賞賛よりもむしろ堅実なアドバイスを与えられるでしょう。 注:Model-View-の神秘的な3番目の部分に「ブリッジ」を使用しますか?それが「すべき」であるという潜在意識の提案を避けるため。 モデル データに対する権限です。 リクエストされた変更に関する情報をブリッジから受け取ります。 データが他のデータにどのように関連するかについてのすべてのロジックを含み、実行します。 データが変更されたときにブリッジに通知します(ブリッジが関心を示したデータについて)。表現の編集:外部のサブスクライバー(何も知らない)が、その状態または計算結果をモニターできるようにします。 ビューに関する知識がありません。 見る ユーザーにデータを表示および操作する方法を提供することに関心があります。 ブリッジからデータ更新に関する情報を受け取ります。 ユーザーにデータとコントロールを提示する方法のすべてのロジックを含み、実行します。 ユーザーがモデルに(おそらく)影響を与えるアクションを実行したときに、ブリッジに通知します。 興味のある情報をブリッジに通知します。 モデルに関する知識がありません。 ブリッジ モデルとビューの間のコーディネーターおよびトランスレーターです。 モデルとビューの間で受け渡される情報に適切なフォーマット変更を加えます。 「誰が何を知る必要があるか」に関する情報を保持します。 モデルとビューの両方の知識がある。 その他の注意事項 より複雑なプログラムでは、複数のモデルが存在するのが一般的です。この状況では、ブリッジは通常、複数のモデル間の調整/翻訳の仕事を引き受けるため、protocall / API / designモデルの構築対象の権限になります。(たとえば、カードゲームプログラムを構築し、代替のデッキシャッフルモデルを構築する場合、ブリッジを使用して、ブリッジとの適切な通信に必要な機能を決定する必要があります。) ビューとモデルが1つだけの小さな単純なプログラムでは、ブリッジがどちらの側でどの機能を使用できるかを「想定」するのが一般的です。ただし、プログラムがより複雑になると、非効率性とバグのある仮定を回避できるように、ビューとモデルが機能をブリッジに報告することをお勧めします。 ほぼカバーしていると思います。どうしても、私が使用する傾向のあるデザインについて質問がある場合は歓迎します。また、提案をお勧めします。 そしていつものように、お時間をいただきありがとうございます。

8
MVCはWebにのみ適用されますか
Model View Controller(MVC)について開発者と話すと、サーバーがエンティティ(MODEL)を構築し、そのモデルの視覚的表現を提供するURLへのリクエストを行うと言うとき、それはほぼ瞬時です。 これは、MVC がWeb専用であることを意味しますか、それともWebアプリケーションを作成するためにMVCを使用する開発者だけの人と会ったことがありますか? デスクトップスタイルのアプリケーションでMVCの使用法はありますか? 私は、パラダイムが初めてであり、MVCのスーパーセットについて知りたい

13
MVCのMはどこにありますか?
アプリケーションをMVCにリファクタリングしようとしていますが、Mの部分にこだわっています。 データベース対応のアプリでは、モデルはアプリのコードに実装されますよね? しかし、その後、データベースには何がありますか?それはモデルではありませんか? (データベースを単純なオブジェクトストアとして使用していません。DB内のデータはエンタープライズ資産です)。

5
単体テストはMVCパターンの主な目的ですか?
最近のインタビューで、質問の1つは「なぜMVCを使用するのですか?」実世界のシステムの多くは、どれほど近いかと答えただけです!保守性、スケーラビリティなどに関しては利点があることを説明しました。しかし、彼らは納得できず、MVCは主に「簡単な単体テストを可能にする」ために使用されると言いました。 私は彼らのものが有効なポイントであることを知っていますが、(i)ユニットテストケースを書かないと決めたとしても、MVCはおそらく選択肢であるため、それが主な理由であるかどうか疑問ですMVCに従ってください。 質問は「ユニットテストはMVCパターンの主な目的ですか?」です。 編集:私は彼らがテスト駆動開発/ NUnitテストケースを書くことの容易さについて言及しているかもしれないと思います。これは、モデルのテストケースを作成できるためです(ビューがモデルの状態の変化を正確に反映している場合)。間違っている場合は修正してください。
14 mvc 

3
MVCでは、DAOはコントローラーまたはモデルから呼び出す必要があります
Controllerクラスから直接呼び出されるDAOに対するさまざまな引数と、ModelクラスからのDAOに対するさまざまな引数を見てきました。実際、MVCパターンに従っている場合、コントローラーはDAOと結合するべきではなく、Modelクラス内部からDAOを呼び出し、コントローラーがモデルクラスを呼び出す必要があるのは、なぜWebアプリケーションからモデルクラスを切り離し、RESTサービスがモデルクラスを使用するなどのさまざまな方法で機能を公開できるからです。 コントローラでDAO呼び出しを記述する場合、RESTサービスが機能を再利用することはできません。両方のアプローチを以下にまとめました。 アプローチ#1 public class CustomerController extends HttpServlet { proctected void doPost(....) { Customer customer = new Customer("xxxxx","23",1); new CustomerDAO().save(customer); } } アプローチ#2 public class CustomerController extends HttpServlet { proctected void doPost(....) { Customer customer = new Customer("xxxxx","23",1); customer.save(customer); } } public class Customer { ........... private void save(Customer customer){ …

3
Model-View-Controller:ユーザーはビューまたはコントローラーと対話しますか?[閉まっている]
閉じた。この質問には、詳細または明確さが必要です。現在、回答を受け付けていません。 この質問を改善したいですか?詳細を追加し、この投稿を編集して問題を明確にします。 5年前に閉鎖されました。 最近、MVCのデザインパターンについて学びました。私はHead First Design Pattern本から学んでいます。 この本によると(私が正しく理解している場合): モデルは、ほとんどのアプリケーションロジックとデータです。 ビューは、基本的にモデルをユーザーに視覚的に表すGUIです。 コントローラーは、ビューとモデルの間の「仲介」と「仲介者」としての役割を果たす責任があります。ビューは、ユーザーがアクションを実行したことをコントローラーに報告し、コントローラーはそれをモデルのメソッド呼び出しに変換します。 しかし、ウェブ上の多くの場所は、私がその本から理解していることと矛盾しています。彼らは一般的に、ユーザーがビューではなくコントローラーと対話することを主張しています。 どちらが本当ですか、それともより一般的ですか?ユーザーはコントローラーと直接対話しますか、それともビューと直接対話しますか?両方のアプローチは受け入れられますか?どちらがより一般的ですか?

1
データベース内のドメインモデルは持続可能なソリューションになりますか?
私は、Microsoftテクノロジーをベースにした中小企業のデータベース開発者として新しい仕事を始めました。私は、ベストプラクティス、設計パターン、テスト、およびプロジェクト管理に関して、学校で教えられたものからどれだけのプラクティスが逸脱しているかに早く気づきました。 私を最も悩ませているのは、メインのデータベース開発者(以下、「ジョン」と呼びます)がデータベースにモデルスキーマを保持する方法です!これを行うには、3つの「マジック」テーブルを使用します。1つはデータベーススキーマ用、1つはテーブル用、もう1つは列用です。 レコードを「テーブル」テーブルに挿入すると、実際の対応するテーブルが(データベーストリガーを介して)生成されます。「Rows」テーブルに行を挿入すると、参照されているテーブルがその行で更新されます。これらは、彼の手作りのC#プログラムによって順番に読み取られ、C#モデルを生成します。これは、フロントエンド開発者がコントローラーおよび外部向けに使用します。 これとは別に、ほとんどの開発はASP.NET MVCフレームワークに従って行われます。 このアプローチにはいくつかの欠陥があります。 ORMを維持するために彼が必要であり、そうする時間はめったにありません(ジョブのセキュリティは良いです!) 「テーブル」および「行」テーブルのトリガーに欠陥があります。テーブルの更新も、チェック制約や「高度な」機能もサポートしていません。それらを確実に改善することはできましたが、これが道筋かどうかはまだわかりません。 データベース内のプログラムロジックを維持することは、奇妙で制限されているように感じます(ただし、C#を使用してモデルを拡張することは可能です)。 彼のC#モデルジェネレーターは、3人のうちの1人(私は1人)によって手動で実行する必要があり、まだ自動化されたビルドプロセスに含まれるほど成熟していません。 Entity Frameworkのような真のテスト済み製品への段階的導入を提案した人もいますが、彼はそれを却下し、ビジネスロジックをコード層に保持することは小規模なアプリケーションとスタートアップのブートストラッププロジェクトにのみ適していると主張しました。 この投稿は、意見を述べた議論のように見えるものに向かっていますが、それは私の意図ではありません。私たちのアーキテクチャのアプローチに関する明確化が必要です。 データベースにドメインモデルを保持することは、成長中の企業にとって持続可能なソリューションになりますか?

4
JSON応答にHTMLマークアップを含める必要がありますか?
eコマースサイトで、カートにアイテムを追加するときに、選択可能なオプションを含むポップアップウィンドウを表示したいと思います。iPod Shuffleを注文していて、彫刻する色とテキストを選択する必要があるとします。 ウィンドウをモーダルにしたいので、Ajax呼び出しで生成されたライトボックスを使用しています。現在、2つのオプションがあります。 オプション1:データのみを送信し、JavaScriptを使用してHTMLマークアップを生成する これの良い点は、Ajaxリクエストを最小限に抑えて、データをマークアップと混合しないことです。 この点でそれほど優れていないのは、サーバー側のテンプレートエンジンを使用する代わりに、JavaScriptを使用してレンダリングを行う必要があることです。クライアント側のテンプレートソリューションを使用して、アプローチを少しクリーンアップできる場合があります。 オプション2:HTMLマークアップを送信する これの良い点は、残りのレンダリングタスク(Django)で使用しているのと同じサーバー側テンプレートエンジンを使用して、ライトボックスのレンダリングを実行できることです。JavaScriptは、HTMLフラグメントをページに挿入するためにのみ使用されます。そのため、レンダリングは明らかにレンダリングエンジンに委ねられます。私には理にかなっています。 しかし、何らかの理由で、Ajax呼び出しでデータとマークアップを混合することに不安を感じています。何が私を不安にさせているのか分かりません。つまり、すべてのWebページが提供されるのと同じ方法で、データとマークアップが正しいのですか?
13 mvc  django  templates  json 

4
モデルビューコントローラーの説明
動的Webサイトの開発に関する私の経験は、主にJavaサーブレットに限定されています。Tomcatを使用してさまざまなJavaサーブレットを開発してきましたが、このテクノロジーとフロントエンドのクライアント側のHTML / CSS / Javascriptにかなり精通していると言うことをためらいません。 「動的なWebサイト」と思うとき、ユーザーはクエリ文字列でURLを要求し、サーバーはクエリを受信し、クエリに応答するためにHTMLを動的に出力します。これには、表示用に要求されたデータをフェッチするために、データベースとの通信が含まれることがよくあります。これは基本的にdoGetJavaのメソッドの背後にある考え方HttpServletです。 しかし、最近では、DjangoやRuby on Railsなどの「Framework Controller」アーキテクチャを活用する新しいフレームワークについてますます耳にしています。MVCを説明するさまざまな 記事を読みましたが、その利点を本当に理解するのに苦労しています。一般的な考え方はUIロジックからビジネスロジックを分離することであると理解していますが、これが通常のWebプログラミングと実際に異なることを理解できません。Webプログラミングは、その性質上、ビジネスロジック(バックエンドサーバー側プログラミング)をUIプログラミング(クライアント側HTMLまたはJavascript)から分離することを余儀なくされます。これは、両者がまったく異なるプログラミング領域に存在するためです。 質問: Javaサーブレットのようなものに対してMVCが提供するもの、さらに重要なことは、 MVCとは何であり、Javaサーブレット(またはCGIのような古いもの)?可能であれば、MVCを説明するときに、MVCがWeb開発プロセスにどのように適用され、どのように有益であるかを示す例を提供してください。

5
コントローラーはビューとモデルについて知っている必要がありますか?またはその逆?
私はこれを行う必要があるかどうかを概念的に理解しようとしています: item = Model() screen = View() brain = Controller(item, screen) またはこれ.. brain = Controller() item = Model(brain) screen = View(brain) またはこれ.. class Controller(): def __init__(self): item = Model(self) screen = View(self) または完全に何か他のもの?
13 mvc 

4
モデルとビューを扱うときの切り替えとポリモーフィズム
私の問題に対するより良い解決策を見つけることができません。要素のリストを表示するView Controllerがあります。これらの要素は、B、C、Dなどのインスタンスになり、Aから継承できるモデルです。したがって、そのView Controllerでは、各項目はアプリケーションの異なる画面に移動し、ユーザーがそれらのいずれかを選択するとデータを渡す必要があります。私の頭に浮かぶ2つの選択肢は次のとおりです(構文を無視してください、それは特定の言語ではありません) 1)スイッチ(私はそれが悪いことを知っています) //inside the view controller void onClickItem(int index) { A a = items.get(index); switch(a.type) { case b: B b = (B)a; go to screen X; x.v1 = b.v1; // fill X with b data x.v2 = b.v2; case c: go to screen Y; etc... } } 2)多型 …

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.