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

今日、MVCアプリケーションについて熱く議論しました。MVC（ASP.NET）で記述されたWebサイトがあり、通常はビューで何かを実行するパターンに従います->コントローラーを押す->コントローラーがモデルを構築します（データを取得するマネージャーを呼び出し、モデルを構築しますコントローラのメソッド自体）->モデルが表示されます->すすぎと繰り返し。 彼は、私たちのコードが密結合しすぎていると言った。たとえば、デスクトップアプリケーションも必要な場合、既存のコードを使用することはできません。 彼が言った解決策とベストプラクティスは、APIを構築し、APIの上にWebサイトを構築し、デスクトップアプリケーション、モバイルアプリなどを構築することは非常に簡単です。 これは、さまざまな理由で私にとって悪い考えのようです。 とにかく、このプラクティスを議論するかもしれないグーグルで何も見つけられないようです。誰もが長所、短所、なぜそうすべきか、なぜそうすべきではないか、さらに読むべきかについての情報を持っていますか？ 悪い考えだと思ういくつかの理由： バックエンドをAPIから実行するにはあまりにも抽象的です。あなたはそれをあまりにも柔軟にしようとしているので、それは管理不能な混乱になります。 MVCに組み込まれているものはすべて、役割や認証など、役に立たないようです。たとえば、[Authorize]属性とセキュリティ。独自にロールする必要があります。 すべてのAPI呼び出しにはセキュリティ情報が添付されている必要があり、トークンシステムなどを開発する必要があります。 プログラムが実行する機能ごとに、完全なAPI呼び出しを記述する必要があります。実装するほとんどすべてのメソッドは、APIから実行する必要があります。すべてのユーザーのGet / Update / Deleteに加えて、ユーザー名の更新、グループへのユーザーの追加など、他の各操作のバリアントがあり、それぞれが個別のAPIコールになります。 APIに関しては、インターフェイスや抽象クラスなどのあらゆる種類のツールが失われます。WCFのようなものには、インターフェイスに対する非常に乏しいサポートがあります。 ユーザーを作成するメソッド、または何らかのタスクを実行するメソッドがあります。50人のユーザーを作成する場合は、50回呼び出すだけです。このメソッドをAPIとして実行することを決定すると、ローカルWebサーバーは名前付きパイプに接続でき、問題はありません-デスクトップクライアントもヒットできますが、突然、ユーザーの一括作成にはインターネット上でAPIを50回ハンマーする必要があります。良くない。したがって、バルクメソッドを作成する必要がありますが、実際にはデスクトップクライアント用に作成するだけです。この方法では、a）統合するものに基づいてAPIを変更する必要があり、直接統合することはできません。b）余分な関数を作成するためにより多くの作業を行う必要があります。 ヤグニ。たとえば、1つのWebアプリケーションと1つのWindowsアプリケーションなど、まったく同じように機能する2つのアプリケーションを作成することを特に計画しているのでなければ、膨大な量の開発作業が必要になります。 エンドツーエンドでステップスルーできない場合、デバッグははるかに困難になります。 多くのやり取りを必要とする独立した操作がたくさんあります。たとえば、いくつかのコードは現在のユーザーを取得し、ユーザーが管理者ロールにあることを確認し、ユーザーが属する会社を取得し、他のメンバーのリストを取得し、それらをすべて送信しますEメール。そのためには、多くのAPI呼び出しが必要になるか、必要な特定のタスクに特注のメソッドを記述する必要があります。特注のメソッドの唯一の利点は速度ですが、欠点は柔軟性に欠けることです。 おそらく、これらの理由のいくつかが私の頭上にあります。 2つの同一のアプリケーションが本当に必要な場合を除き、私には好感が持てますが、それだけの価値はありません。このように構築されたASP.NETアプリケーションを見たことがありません。2つの個別のアプリケーション（APIとコード）を記述し、両方をバージョン管理する必要があります（ユーザーページに新しいフィールドが追加された場合、 dは、APIと消費コードを同時に更新して悪影響を与えないようにするか、堅牢性を維持するために多くの追加作業を行う必要があります）。 編集：いくつかの素晴らしい反応、本当にこれが今何を意味するのか良いアイデアを得るために始めています。それでは、私の質問を拡張するために、このAPI構造に従うようにMVCアプリをどのように構成しますか？ たとえば、ユーザーに関する情報を表示するWebサイトがあります。MVCには、次のものがあります。 ビュー-UserViewModelコントローラーを表示する（CS）HTMLページ-GetUser（）を呼び出し、GetUserメソッドを持つビューマネージャークラス（APIの一種）に渡すUserViewModelを作成します。 コントローラーはGetUser（）を実行しますが、デスクトップアプリも必要です。これは、GetUserが何らかのAPIを介して公開される必要があることを意味します。TCP接続、WCF、またはおそらくRemotingが必要になる場合があります。永続的な接続が不安定なため、RESTfulなモバイルアプリも必要です。 それでは、GetUser（）メソッドがあり、コードが実行するWCF Webサービスごとに、各APIを作成しますreturn new UserManager().GetUser()か？そして、同じことを行うMVC 4 Web APIメソッド？MVCコントローラーメソッドでGetUserを直接呼び出し続けていますか？ または、3つすべて（Web API RESTサービス）で機能するソリューションを選択し、その上にすべてを構築して、3つすべてのアプリがAPI呼び出し（ローカルコンピューターに対してmvc呼び出し）を行うようにします。 そして、これは単なる理論上の完璧なシナリオですか？特に、RESTfulな方法で操作を行えるように開発する必要がある場合、この方法で開発する際に大きなオーバーヘッドが発生することがあります。これのいくつかは返信で取り上げられていると思います。 編集2：より多くのものを読んだ後、私はそれを説明するかもしれないと思うコメントを下に入れました。この質問は、私が考えるちょっとしたトリックの質問です。APIとしてバックエンドを書くと、すべて（mvcアプリ、デスクトップアプリ、モバイルアプリ）が何かを行うために呼び出す単一のWebサービスがあるべきだと思って混乱しました。 私が思いついた結論は、ビジネスロジックレイヤーが正しく分離されていることを確認することです。コードを見て、すでにこれを行っています。コントローラーはGetUser()マネージャーを呼び出し、それからビューモデルを作成してビューでレンダリングします。実際、ビジネスロジック層は APIです。ただし、デスクトップアプリから呼び出したい場合は、WCFサービスのようなものを記述して、呼び出しを容易にする必要があります。GetUser()コードを含むWCFメソッドを呼び出すだけでもreturn MyBusinessLayer.GetUser()十分です。したがって、APIはビジネスロジックであり、WCF / Web APIなどは、外部アプリケーションに呼び出しを許可するためのほんの一握りのコードです。 そのため、必要なものに応じてビジネスロジックレイヤーをさまざまなAPIでラップする必要があり、他のアプリで実行したい操作ごとにAPIメソッドを記述する必要があるというオーバーヘッドがあります。認証を行う方法を整理しますが、ほとんどの部分で同じです。ビジネスロジックを別のプロジェクト（クラスライブラリ）に固定すれば、おそらく問題はありません！ この解釈が正しいことを願っています。それが生成したすべての議論/コメントをありがとう。

322 mvc  asp.net-mvc  api-design 

真面目なプログラマーとして、MVCとは何かという質問にどのように答えますか？ 私の考えでは、MVCは一種の曖昧なトピックです。そのため、視聴者が学習者である場合は、論争の対象とはならない一般的な用語で自由に説明できます。 ただし、知識豊富な聴衆、特にインタビュアーと話している場合、「それは正しくない！...」という反応のリスクを冒さないための方向性を考えるのに苦労しています。私たちは皆、実世界での経験が異なり、同じMVCの実装パターンに2回出会ったことはありません。 具体的には、厳密性、コンポーネント定義、部品の分離（どの部品がどこに適合するか）などに関して意見の相違があるようです。 それで、MVCを正しく、簡潔で、議論の余地のない方法でどのように説明すればよいですか？

202 design-patterns  mvc  definition 

最近、Webアプリケーションを実行している人はすべてにMVCを使用したいと考えています。ただし、このパターンを使用するように説得することは困難です。一般的な考え方は、プログラムを表すフロントエンドからバックエンドロジックを分離することだと理解しています。一般的に、ビューは常にある程度コントローラーに依存しているようで、最終的にはモデルに依存します。コントローラーを追加することで得られる利点がわかりません。「これがアプリケーションの設計方法だ」という誇大広告をたくさん読んだことがありますが、どこに行くべきかがまだわからないかもしれません。私がMVCについて他の人と話すときはいつでも、誰がどのカテゴリに属する​​かについて異なる考えを持っているようです。 それでは、なぜMVCを使用する必要があるのですか？フロントエンドをバックエンドロジックから分離するだけでMVCを使用すると、何が得られますか？（このパターンのほとんどの「利点」は、インターフェイスを実装から分離するだけで得られ、別の「コントローラ」を持つ目的を説明できません）

74 design-patterns  mvc  rationale 

私は常に、ビジネスロジックはコントローラー内になければならず、コントローラーは「中間」部分であるため、静的のままであり、モデル/ビューはインターフェースを介してカプセル化する必要があると考えていました。そうすれば、他に何も影響を与えずにビジネスロジックを変更し、複数のモデル（データベース/ストレージのタイプごとに1つ）および多数のビュー（たとえば、異なるプラットフォーム用）をプログラムできます。 この質問で、ビジネスロジックを常にモデルに配置する必要があり、コントローラーがビューと深く関係していることを読みました。 私にとって、それは本当に意味をなさないし、別のデータベース/ストレージのタイプをサポートする手段を持ちたいと思うたびに、ビジネスロジックを含むモデル全体を書き直さなければならないことを意味します。 また、別のビューが必要な場合は、ビューとコントローラーの両方を書き換える必要があります。 誰かがそれがなぜであるか、または私がどこかで間違った場合に説明してもらえますか？

70 mvc  business-logic 

典型的な（適切に設計された）MVC Webアプリでは、データベースはモデルコードを認識せず、モデルコードはコントローラーコードを認識せず、コントローラーコードはビューコードを認識しません。（ハードウェアと同じくらい、あるいはそれ以上のレベルで開始することもでき、パターンも同じになると思います。） 別の方向に進むと、1つ下のレイヤーに移動できます。ビューはコントローラーを認識できますが、モデルは認識できません。コントローラーはモデルを認識できますが、データベースは認識できません。モデルはデータベースを認識できますが、OSは認識できません。（より深いものはおそらく無関係です。） なぜこれが良いアイデアなのか直感的に把握できますが、明確に説明することはできません。なぜこの単方向スタイルのレイヤー化が良いアイデアなのでしょうか？

66 architecture  mvc  encapsulation  layers 

OOPの背後にある主な考え方は、単一のエンティティ（オブジェクト）でデータと動作を統合することです。手続き型プログラミングには、データと、データを変更する個別のアルゴリズムがあります。 Model-View-Controllerパターンでは、データとロジック/アルゴリズムはそれぞれ別個のエンティティ、モデル、コントローラーに配置されます。同等のOOPアプローチでは、モデルとコントローラーを同じ論理エンティティに配置するべきではありませんか？

62 design  object-oriented  mvc 

私はしばらくコーディングしてきましたが、ほとんどはスクリプトと単純なアプリケーションです。Web Appsの開発と適切なMVCアーキテクチャの使用がすべての新しい役割に移行したため、そのすべてについて非常に迅速に学習しようと必死です。 この質問が「MVCアーキテクチャのベストプラクティス」とあまり似ていないことを願っていますが、いくつかの異なるチュートリアルを進めていると、いくつかの異なるコントローラが複数あることがわかりました。 1つのWebアプリに必要なコントローラーの数は？ 例がなければ答えるのは難しいと思いますので、例を示します。 応用： ユーザーがログインします。 ユーザーは、次の3つのいずれかを実行できます 。a ）ファイルをアップロードします（メタデータとともにmongodbデータベースに保存されます）。 b） ファイルを検索します。 c） ログアウトします。 私の質問は一般的な質問ですが、答えようとしている人を助けるために例を挙げました。

54 web-development  design-patterns  programming-practices  mvc 

Model-View-Controller（MVC）およびModel-View-Presenter（MVP）パターンについて3日間読んでいます。そして、私を非常に悩ませる1つの質問があります。既にMVCがあったのに、ソフトウェアデザイナーがMVPを発明したのはなぜですか？ MVCが解決しなかった（またはひどく解決した）が、MVPが解決できる問題は何ですか？MVPが解決するのはどの問題ですか？ MVPの歴史と説明、またはMVCとMVPの違いに関する記事をたくさん読んでいますが、私の質問に対する明確な答えがありませんでした。 私が読んだ記事の1つで、次のように言われました。 次に、Model View Presenterを使用します。これは、最新のコンポーネントベースのグラフィカルユーザーインターフェイスに適用した場合のMVCパターンの不備に対する応答でした。最新のGUIシステムでは、GUIコンポーネント自体が、中央のコントローラーではなく、マウスの動きやクリックなどのユーザー入力を処理します。 だから、理解できませんが、実際には別の方法で、GUIコンポーネントがユーザー入力を自分で処理しないようにすることはできますか？そして、「自分で処理する」とはどういう意味ですか？

49 design  design-patterns  mvc  mvp 

まず、これは軽視されている質問/領域であるように思われるので、この質問を改善する必要がある場合は、他の人に利益をもたらすことができる素晴らしい質問にしてください！試してみたいアイデアだけでなく、この問題を解決するソリューションを実装した人々からのアドバイスやヘルプを探しています。 私の経験では、アプリケーションには2つの側面があります。主にドメイン駆動型で、ユーザーがドメインモデル（アプリケーションの「エンジン」）とやり取りする「タスク」側と、ユーザーがタスク側で何が起こるかに基づいてデータを取得します。 タスク側では、リッチなドメインモデルを備えたアプリケーションにはドメインモデルのビジネスロジックが必要であり、データベースは主に永続化のために使用する必要があることは明らかです。懸念の分離、すべての本はそれについて書かれています、私たちは何をすべきか、素晴らしいを知っています。 レポート側についてはどうですか？データウェアハウスは受け入れ可能ですか、それともデータベースとビジネスそのものにビジネスロジックを組み込んでいるため、設計が悪いのでしょうか。データベースのデータをデータウェアハウスデータに集約するには、データにビジネスロジックとルールを適用している必要があります。そのロジックとルールはドメインモデルからではなく、データ集約プロセスからのものです。それは間違っていますか？ 私は、ビジネスロジックが広範囲にわたる大規模な財務およびプロジェクト管理アプリケーションに取り組んでいます。このデータのレポートを作成するとき、レポート/ダッシュボードに必要な情報を取得するために多くの集計を行うことが多く、集計には多くのビジネスロジックが含まれています。パフォーマンスのために、高度に集約されたテーブルとストアドプロシージャを使用してこれを行っています。 例として、アクティブなプロジェクトのリストを表示するためにレポート/ダッシュボードが必要だとしましょう（10,000個のプロジェクトを想像してください）。各プロジェクトには、次のような一連のメトリックが必要です。 総予算 これまでの努力 燃焼速度 現在の燃焼速度での予算枯渇日 等 これらのそれぞれには、多くのビジネスロジックが含まれます。そして、私は単に数字の乗算やいくつかの単純なロジックについて話しているのではありません。予算を得るために話しているのは、各従業員の時間（一部のプロジェクトでは、他のプロジェクトでは乗数があります）に1つずつ、500の異なるレートのレートシートを適用し、費用や適切なマークアップなどを適用する必要があることですロジックは広範です。クライアントにとって妥当な時間内にこのデータを取得するには、多くの集約とクエリのチューニングが必要でした。 これは最初にドメインを介して実行する必要がありますか？パフォーマンスはどうですか？単純なSQLクエリを使用しても、クライアントが妥当な時間内に表示するのに十分な速度でこのデータを取得することはほとんどありません。これらすべてのドメインオブジェクトをリハイドレートし、アプリケーションレイヤーでデータを混合および照合して集約する場合、またはアプリケーションでデータを集約しようとする場合、クライアントにこのデータを十分に速く取得しようとすることは想像できません。 これらのケースでは、SQLはデータの処理に優れているように思われますが、使用しないのはなぜですか？ただし、ドメインモデルの外部にビジネスロジックがあります。ドメインモデルおよびレポート集計スキームでビジネスロジックを変更する必要があります。 ドメイン駆動設計と優れた実践に関して、アプリケーションのレポート/ダッシュボード部分をどのように設計するかについて、私は本当に困っています。 MVCはデザインフレーバーデュジュールであり、現在のデザインで使用しているため、MVCタグを追加しましたが、レポートデータがこのタイプのアプリケーションにどのように適合するかわかりません。 本、デザインパターン、グーグルのキーワード、記事など、この分野での助けを探しています。このトピックに関する情報が見つかりません。 編集と別の例 今日出会った別の完璧な例。顧客が顧客営業チームのレポートを望んでいる。彼らは単純なメトリックのように見えるものを望んでいます： 各営業担当者の現在までの年間売上はいくらですか？ しかし、それは複雑です。各販売員は複数の販売機会に参加しました。勝った人もいなかった人もいます。各販売機会には、それぞれの役割と参加ごとに、販売に対するクレジットの割合が割り当てられた複数の販売員がいます。それでは、このためにドメインを通過することを想像してください。すべての営業担当者のデータベースからこのデータを引き出すために必要なオブジェクトの再水和の量： すべての取得SalesPeople- > それぞれが得るために彼らのSalesOpportunities- > 各販売の彼らの割合を取得し、その販売量を算出するために 、すべての彼らの最大の追加SalesOpportunity販売量を。 そして、それは1つのメトリックです。または、迅速かつ効率的に実行し、高速に調整できるSQLクエリを作成できます。 編集2- CQRSパターン CQRSパターンについて読んだことがありますが、興味深いことに、Martin Fowlerもテストされていないと言います。それで、過去にこの問題はどのように解決されましたか。これは、何らかの点で全員が直面していなければなりません。成功の実績を持つ確立されたアプローチまたは使い古されたアプローチとは何ですか？ 編集3-レポートシステム/ツール このコンテキストで考慮すべきもう1つのことは、レポートツールです。Reporting Services / Crystal Reports、Analysis Services、Cognoscentiなどはすべて、SQL /データベースからのデータを想定しています。これらのデータが後であなたのビジネスに届くとは思いません。それでも、彼らと彼らのような人々は、多くの大規模システムのレポートの重要な部分です。これらのシステムのデータソースやレポート自体にもビジネスロジックがある場合、これらのデータは適切に処理されますか？

44 mvc  architecture  domain-driven-design  reporting  data-warehouse 

データフォームを介してデータベースにレコードを追加する簡単なMVC Javaアプリケーションを作成しました。 私のアプリはデータを収集し、検証して保存します。これは、データがさまざまなユーザーからオンラインで調達されているためです。データは本質的にほとんど数値です。 データベース（SQLサーバー）に格納されている数値データで、計算を実行して結果を表示するアプリを作成します。ユーザーは計算の実行方法に関心がないため、カプセル化する必要があります。ユーザーは、単純な計算データ（たとえば、A列データからB列データをC列データで除算したもの）のみを表示できる必要があります。同じストアドプロシージャを記述する方法は知っていますが、3層アプリが必要です。 データベースにレコードとして入れて、計算を実行して処理したデータが必要です。元のデータは影響を受けないまま、計算後の新しいデータは新しいエンティティレコードとしてデータベースに保存する必要があります。 このバックグラウンド計算用のコードはどこに書くべきですか？ルールとビジネスロジックなので、新しいJavaBeansファイルに入れる必要がありますか？

44 web-development  mvc  object-oriented-design  business-logic 

数年前に実際にコードを整理し始めて以来、MVC / MV *を使用しています。私はそれを長い間使ってきたので、コードを構造化する他の方法を考えることすらできず、インターンになってからのすべての仕事はMVCベースでした。 私の質問は、MVCの没落は何ですか？どのような場合にMVCはプロジェクトにとって悪い選択であり、（より）正しい選択は何ですか？MVCの代替案を調べると、ほとんどすべての結果は異なるタイプのMVCにすぎません。 これが閉じられないように範囲を絞り込むには、Webアプリケーションの場合を考えてみましょう。私はさまざまなプロジェクトのバックエンドとフロントエンドで作業しているので、フロントエンドやバックエンドだけとは言えません。

43 design-patterns  mvc 

コントローラがサービスの代わりにリポジトリを呼び出すのは悪い習慣ですか？ さらに説明する： 優れた設計では、コントローラーがサービスを呼び出し、サービスがリポジトリを使用することがわかります。 ただし、コントローラーにはロジックがない場合や必要ない場合があり、dbからフェッチしてビューに渡すだけでよい場合があります。 そして、私はリポジトリを呼び出すだけでそれを行うことができます-サービスを呼び出す必要はありません-それは悪い習慣ですか？

43 design-patterns  object-oriented  mvc  repository 

私はASP.NET MVC / Web APIを使用してきましたが、現在、Angularを使用し始めていますが、それらを混合する適切な方法については明確ではありません。 Angularを使用しても、MVCサーバー側の概念にはまだ価値がありますか？または、厳密にWeb APIを使用して、角度付きHTTP呼び出しのデータを取得する必要がありますか？ VSテンプレートに不要なものがたくさん追加されている場合に使用する必要のある開始点はもっと少なくなっていますか？ サーバー側=純粋なデータとクライアント側=純粋なHTML処理の厳密な分割のアイデアが好きです。

40 javascript  mvc  asp.net-mvc 

アプリケーションのコントローラーコードで表されるビジネスロジックがある場合があります。これは通常、モデルから呼び出すメソッドやそれらを渡す引数を区別するロジックです。 これの別の例は、ビジネスルールのセットに従って、モデルから返されたデータをフォーマットまたはサニタイズするために機能するコントローラーに存在するユーティリティ関数のセットです。 これは機能しますが、災害といちゃつくかどうか疑問に思っています。コントローラーとモデル間で共有されるビジネスロジックがある場合、2つのレイヤーは分離できなくなり、コードを継承する人は、ビジネスロジック関連のコードの場所の不均一性によって混乱する可能性があります。 私の質問は、コントローラーでどのくらいのビジネスロジックを許可する必要があるか、また、ある場合、どのような状況ですか？

39 design-patterns  mvc 

私は現在、ソロのプライマリ開発者として、2人の会社で働いています。上司がクライアントを取得し、いくつかのpngデザインテンプレートをモックアップして、私に引き渡します。 このシステムはうまく機能しており、本当に楽しんでいます。 私が取り組んでいるプロジェクトの種類は、中小企業向けであり、通常はCMSシステムが必要です。最初から開発し、カテゴリ、タグ、製品などを追加/編集/削除するためにクライアント用にカスタマイズしたバックエンドを構築し、渡されたデザインテンプレートに従ってフロントエンドに出力します。時間が経つにつれて、ショッピングカート/注文機能やその他の一般的なeコマースタイプの機能により、プロジェクトの複雑さが増しました。 繰り返しますが、このシステムは正常に機能しており、本当に楽しんでいます。 私の問題は、プログラマーとしての個人的な成長です。プログラミングブログを読んだり、stackexchangeをチェックしたり、提案されたプログラミング本（現在のところ「The Pragmatic Programmer」で、これまでのところ本当に良い）を読んだり、脳のエクササイズ（lumosity.comとkhanacademy math問題）をしたり、たくさんの運動やその他の個人的な発達型の活動。 私は、フィードバック、批評を見逃していると感じずにはいられません。私の上司は素晴らしく、私の仕事に関して賞賛を決してneverしませんが、残念ながら彼は私のコードをチェックするのに忙しいか、正直なところ、彼の専門分野の1つではないと考えているため、フィードバックを提供できません。 私は何を間違っているのか、何を正しくしているのかを知りたい。コントローラーにそれほど多くのロジックを配置する必要がある場合、コードを十分に変調していますか？ だから私がやったことは、小さな「家族予算」アプリを開発し、私が現在知っている方法と同じくらいきれいにそして効果的にそれをやろうとしたことです。 私が知りたいのは、このアプリを提出できる場所があり、ベテランの開発者にフィードバックを提供してもらうことです。「codereview.stackexchange」のような私のコードのサブセクションだけでなく、私が批判したいのは私のワークフロー全体です。 これは多くの質問であり、主なアドバイスはチーム内で仕事を探すことだと思います。これは確かに後の方で検討しますが、今のところは現在の仕事を続けたいと思います。雇用状況、しかしあまりにも多くの悪い習慣を開発したくない。 わかりやすくするためにさらに情報を提供できるかどうか、またはこのタイプの質問にこれが適切な場所でない場合は、事前に謝罪します。私はこのコミュニティがよりよく考えられた応答を促進すると感じたので、redditを使用したくありませんでした。

38 learning  object-oriented  programming-practices  education  mvc