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

私は過去にこの主題について多くのことを読み、ボブおじさんのこのような興味深い講演をいくつか見てきました。それでも、デスクトップアプリケーションを適切に設計し、UI側の責任とロジック側の責任を区別することは常に非常に難しいと感じています。 優れた実践の非常に短い要約は、このようなものです。UIから切り離したロジックを設計する必要があります。これにより、どの種類のバックエンド/ UIフレームワークに関係なく（理論的に）ライブラリを使用できるようになります。これが意味することは、基本的にUIは可能な限りダミーであるべきであり、重い処理はロジック側で行われるべきだということです。別の言い方をすれば、文字通り、コンソールアプリケーション、Webアプリケーション、またはデスクトップアプリケーションで素敵なライブラリを使用できます。 また、ボブおじさんは、どのテクノロジーを使用するとさまざまなメリットが得られるか（良いインターフェース）を議論することを提案します。 ですから、この質問は非常に広範な質問であり、インターネット全体で何度も議論されてきました。そこで、何か良いものを得るために、pyqtでMCVを使用しようとする非常に小さなダミーの例を投稿します。 import sys import os import random from PyQt5 import QtWidgets from PyQt5 import QtGui from PyQt5 import QtCore random.seed(1) class Model(QtCore.QObject): item_added = QtCore.pyqtSignal(int) item_removed = QtCore.pyqtSignal(int) def __init__(self): super().__init__() self.items = {} def add_item(self): guid = random.randint(0, 10000) new_item = { "pos": [random.randint(50, 100), …

20 design  python  mvc  gui  coupling 

それらは同じことを意味しますか（アクションへのURLの添付、またはURLへのアクションの添付）、欠落している違いはありますか？ 例：http : //github.com/dannyvankooten/PHP-Router vs. http://konstrukt.dk

19 mvc  routing 

Ruby on Railsチュートリアルで、経験豊富な開発者はMVCを自分で接続するコードを書くのが好きなので、scaffoldingを使用しないことを示唆するものを読みました。 別の場所で、私は足場を使用することをお勧めします。それは、コードを見てやり取りする他の人があなたが何をしているのか理解できるように、慣習に固執するのに役立つからです。 Ruby on Railsは初めてですが、MVCやWebアプリケーションは初めてではありません。一般に、scaffoldingの慣習に固執してガイドしてもらうべきでしょうか？

18 ruby  ruby-on-rails  mvc 

ビューをロジックから分離するMVCのようなパターンがあることは知っていますが、Winformアプリケーションでそれらがどれほど一般的かはわかりません。 C＃Winformアプリケーションの場合、a Formから始めてUIコンポーネントを徐々に追加し、コンポーネントのイベントに対して（click、textchanged...）関数を呼び出すか、ロジックを直接記述します！ 私はそれが悪い習慣であることは知っていますが、Visual Studioでそのようなプロジェクト（テンプレート、フレームワーク、開始点）を開始する最善の方法は何なのかわかりません。MVCが唯一の解決策ですか？私はどんなプロジェクトでもそれをすべきですか？！ 開始するためのガイドラインまたは軽量フレームワークを受け取りたいです。

18 c#  mvc  winforms 

リアルタイムの単一ページアプリケーションを開発する過程で、ユーザーに最新のデータを提供するためにwebsocketを徐々に採用しています。この段階で、アプリの構造を破壊しすぎていることに気がつき、この現象の解決策を見つけることができませんでした。 詳細に入る前に、ほんの少しのコンテキスト： webappはリアルタイムSPAです。 バックエンドはRuby on Railsにあります。リアルタイムイベントはRubyによってRedisキーにプッシュされ、その後、マイクロノードサーバーがそれをプルバックしてSocket.Ioにプッシュします。 フロントエンドはAngularJSにあり、Nodeのsocket.ioサーバーに直接接続します。 サーバー側では、リアルタイムになる前に、明確なコントローラー/モデルベースのリソース分離があり、それぞれに処理が関連付けられていました。この古典的なMVCの設計は、ユーザーにWebソケットを介してプッシュを開始した直後に、完全に細断された、または少なくともバイパスされました。これで、すべてのアプリが多かれ少なかれ構造化されたデータを流す単一のパイプができました。そして、私はそれがストレスだと感じます。 フロントエンドでの主な懸念は、ビジネスロジックの重複です。ユーザーがページを読み込むとき、古典的なAJAX呼び出しを介してモデルを読み込む必要があります。しかし、リアルタイムのデータフラッディングも処理する必要があり、クライアントサイドモデルの一貫性を維持するために、クライアントサイドのビジネスロジックの多くを複製しています。 いくつかの調査の後、いくつかの特定のトピックを念頭に置いて、現代のWebアプリのアーキテクチャをどのように設計することができ、どのように設計するべきかについてのアドバイスを提供する良い投稿、記事、書籍などは見つかりません： サーバーからユーザーに送信されるデータの構造化方法 「このリソースは更新されたので、AJAX呼び出しでリロードする必要があります」などのイベントのみを送信するか、更新されたデータをプッシュし、初期AJAX呼び出しでロードされた以前のデータを置き換えますか？ 送信されたデータに一貫性のあるスケーラブルなスケルトンを定義する方法は？これはモデル更新メッセージですか、または「blablablablahにエラーがありました」メッセージです バックエンドのどこからでもすべてに関するデータを送信しない方法 サーバー側とクライアント側の両方でビジネスロジックの重複を減らす方法

17 web-applications  mvc  websockets 

したがって、私がかなり頻繁に遭遇する状況は、私のモデルが次のいずれかを開始する状況です。 たくさんの方法でモンスターに成長する または SQLの一部をそれらに渡すことができるため、数百万の異なるメソッドを必要としないほど柔軟です たとえば、「ウィジェット」モデルがあるとします。いくつかの基本的な方法から始めます。 get（$ id） insert（$ record） update（$ id、$ record） 削除（$ id） getList（）//ウィジェットのリストを取得 それはすべてうまくできていますが、いくつかのレポートが必要です。 listCreatedBetween（$ start_date、$ end_date） listPurchasedBetween（$ start_date、$ end_date） listOfPending（） そして、レポートは複雑になり始めます。 listPendingCreatedBetween（$ start_date、$ end_date） listForCustomer（$ customer_id） listPendingCreatedBetweenForCustomer（$ customer_id、$ start_date、$ end_date） これがどこで成長しているのかを見ることができます...最終的には、非常に多くの特定のクエリ要件があるため、大量のメソッドを実装するか、単一の-> query（query $ query）メソッド... ...または単に弾丸を噛んで、次のようなことを始めてください： list = MyModel-> query（ "start_date> X AND end_date <Y AND pending = …

17 design-patterns  mvc 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 MVCフレームワークに関しては、主に2つのコードベース構造があります。問題は、両者に組織的なバグがあるように見えることです。 標準MVC /controller /model /view 問題：関連するコンポーネント（フォーラム、ブログ、ユーザーなど）の分離がない モジュラーMVC /blog /controller /model /view /user /controller /model /view /forum /controller /model /view モジュールベースのシステムを選択すると、問題が残ります。 長い名前（Forum_Model_Forum = forum / model / forum.php）（Zendのように） ファイルシステムis_file()は、フォーラムモデルを持つフォルダーを見つけるために使用しますか？（小花のように） 異なるモジュールを分離しようとしたときにうまく機能する他のMVC構造はありますか？私が見逃しているこれらの構造の利点はありますか？

17 web-applications  mvc  web-framework  file-structure 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 8年前に閉鎖されました。 ...または、より複雑になっていますか？ 最近、MS Webアプリを「適切に」開発するには、多くのことを知る必要があるように思えます。よくわからない悪い昔、データベーステーブル、ASP.NET、ADO.NETがあり、比較的単純な概念を使用してWebアプリを構築しました。 最近では、「正しい」ことを「手助け」するためのフレームワークがたくさんあるように見えますが、これがすべてをより簡単に、より良くすることを確信していません。私はこの感情でかなり小さな少数派になるだろうと感じていますが、物事が少し狂っていると思う他の誰かがそこにいますか？

17 wcf  linq  mvc  entity-framework 

どちらかを持っている方が良いですか 同じテストが成功する確定的なテストスイート 非決定的テストスイート。これは、より多くのケースをカバーする可能性があります。 ？ 例： テストスイートを作成して、MVCアプリケーションのコントローラー機能をテストします。コントローラーは、テスト中の入力としてデータベースからのアプリケーションデータを必要とします。これを行うには2つのオプションがあります。 テストデータベースのどの行を入力として選択するかをハードコーディングします（10行目と412行目など） 乱数ジェネレーターを使用して、データベースからデータを擬似ランダムに選択します（乱数ジェネレーターによって選択された2行） 1つ目は決定論的です。同じリビジョンのコードに対してテストを実行するたびに、同じ結果が得られます。2番目は非決定的です。テストスイートを実行するたびに、異なる結果が得られる可能性があります。ただし、ランダムに選択されたデータは、データエッジケースのより適切な表現である可能性があります。予測不可能なデータをコントローラーに送るユーザーをよりよくシミュレートするかもしれません。 どちらか一方を選択する理由は何ですか？

17 testing  mvc 

私はすべての新しいiOS開発者に次の問題があると確信しています。 これは、2つの基本的な一般的な画面の表示方法です。 1）フォーム画面： 2）テーブルビューコントローラー画面 これまでに、2つの異なるソリューションについて読みました。 最初のソリューション：https://bendyworks.com/single-responsibility-principle-ios/。これは通知に基づいており、View Controllerを（意図）View Modelから完全に分離するため、View Controllerのコードが削減されます。Go-To構造と同様に、コードを壊すという欠点があると思います。次のようになります。 2番目のソリューションは、混雑した同じView Controllerを保持します（ボタンアクションはVC内で実行されるなど）。ただし、TPKeyboardAvoiding、BlocksKitなどのライブラリ、またはそれらのほとんどはカテゴリに基づいたソリューションを使用します。この2番目のソリューションでは、コードは大幅に削減されますが、View Controllerには依然として多くの責任があります。 これらのソリューションについてどう思いますか？どちらが良いですか？より良いものはありますか？

16 mvc  ios  objective-c 

MVCを使用するアプリがありますが、コントローラーの設計方法について少し苦労しています。たとえば、ビューはモデルのデータの一部のみを一度に表示しています。しかし、私はこれがどのように配置されるべきか正確にはわかりません。たとえば、ビューまたはモデルがコントローラーの関数を直接呼び出すのは正常ですか？ある種のインターフェースを通して？または、それらは完全にカプセル化されており、コントローラーまたは互いについて決して知りませんか？ 編集と同じように。これはWebフレームワークで書かれていないカスタムアプリなので、ここではフレームワーク固有の詳細を探しているわけではなく、自分で選択する自由があります。

16 mvc 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 私は学生ですが、すぐにソフトウェア業界に参入することを願っています。MVCソフトウェアパターンについて多くの誇大宣伝があるようです。PHPフレームワークは多くの場合MVCであることに気づきましたが、Web以外の言語についてはどうでしょうか。修士論文（C ++）では、MVCパターンを選択しました。これは、ロジックとユーザーインターフェイスをうまく分離しているためです。 業界では多く使用されていますか？もしそうなら、主な理由は何ですか、他の競合する人気のあるデザインは何ですか？

16 mvc 

私は、長年のSpring MVCから来たDjangoと仕事を始めたばかりで、フォームの実装は少しおかしいと感じています。慣れていない場合、Djangoフォームは、フィールドを定義するフォームモデルクラスから始まります。同様に、Springはフォームをバッキングするオブジェクトから始まります。ただし、Springがフォーム要素をJSP内のバッキングオブジェクトにバインドするためのtaglibを提供している場合、Djangoにはモデルに直接関連付けられたフォームウィジェットがあります。CSSを適用したり、完全にカスタムウィジェットを新しいクラスとして定義するためにフィールドにスタイル属性を追加できるデフォルトのウィジェットがあります。それはすべてあなたのpythonコードに含まれています。それは私には馬鹿げているようです。最初に、ビューに関する情報をモデルに直接入力し、次にモデルを特定のビューにバインドします。何か不足していますか？ 編集：要求されたいくつかのサンプルコード。 ジャンゴ： # Class defines the data associated with this form class CommentForm(forms.Form): # name is CharField and the argument tells Django to use a <input type="text"> # and add the CSS class "special" as an attribute. The kind of thing that should # go in a template …

16 mvc  django 

MVCの方法に関するアドバイスが欲しいだけです。codeigniterを使用していますが、Webサイトのページごとに1つのコントローラーを使用するのが良いのか、それともすべてのページに1つのコントローラーを使用するのが良いのか疑問に思っていました。 ホームページにアクセスし、ログインし、アカウントを作成して管理者に連絡できるシンプルなウェブサイトがあるとしましょう。 frontend（index）、login、account、contact、またはfrontendと呼ばれる1つのコントローラー、またはlogin、createAccount、contactなどのアクションを持つコントローラーを使用する方が良いでしょうか？ 状況で1つのコントローラーを使用するほうが良いかどうかはいつわかりますか？

16 mvc 

単一責任原則は、「クラスには変更の理由が1つあるべきだ」と述べています。 MVCパターンでは、コントローラーの仕事は、ビューとモデルの間を仲介することです。GUIでユーザーが行ったアクションをレポートするためのビューのインターフェースを提供し（ビューの呼び出しを許可するcontroller.specificButtonPressed()など）、データを操作したり操作を呼び出すためにモデルの適切なメソッドを呼び出すことができます（例model.doSomething()） 。 この意味は： ビューにユーザーアクションを報告するための適切なインターフェイスを提供するために、コントローラーはGUIについて知る必要があります。 また、モデルの適切なメソッドを呼び出すことができるように、モデルのロジックについて知る必要があります。 つまり、GUIの変更とビジネスロジックの変更という2つの理由があります。 GUIが変更された場合（新しいボタンが追加された場合など）、コントローラーは、ユーザーがこのボタンを押したことをビューが報告できるように新しいメソッドを追加する必要がある場合があります。 また、モデルのビジネスロジックが変更された場合、モデルの正しいメソッドを呼び出すためにコントローラーを変更する必要があります。 そのため、Controllerには2つの変更可能な理由があります。SRPを壊しますか？

16 design  object-oriented  mvc  single-responsibility