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

私は過去3年間、個人および職場の両方でいくつかのWebアプリケーションプロジェクトを開発してきましたが、少なくとも一部のビジネスロジックがアプリケーションのビューレイヤーで終了する可能性があるかどうかはわかりません。 ほとんどの場合、「ユーザーがオプションxを選択した場合、アプリケーションはユーザーがyの情報を提供できるようにする必要があり、そうでない場合は情報zを提供する必要がある」などの問題があります。または、モデルにいくつかの変更を適用する必要がありますが、ユーザーが明示的に要求するまでコミットしないAJAX操作を実行します。これらは私が遭遇した最も単純な問題の一部であり、ビュー内の複雑なロジックを回避する方法がわかりません。 MVCについて説明した本のほとんどは、通常、サーバー上のデータを更新して表示するCRUD操作など、非常に簡単な例を示していますが、CRUDはほとんどのリッチアプリケーションには当てはまりません。 ビジネスロジックをまったく持たないビューを実現することは可能ですか？

31 web-applications  mvc  view  crud 

Django / Python / Web Developmentを学び始めたばかりです。この問題は、しばらく私を悩ませてきました。 Djangoで複数のテンプレートを使用してアプリケーションを作成しています。私は、基本的にそれぞれのテンプレートへの応答をレンダリングするだけのviews.pyを持ち、DBを構造化したmodels.pyを持っています。テンプレートの1つで、画像をアップロードする必要があります（実行できます）。アップロードされた画像の機能に基づいたロジックを実行する必要があります（まだ実行されていません）。このロジックには、多くの重い計算が含まれます。計算の実行後、ロジックは処理済みの情報（座標）をテンプレートに返す必要があります。 pythonファイルを次々に呼び出すスタンドアロンのPythonデスクトップアプリケーションで、これらすべてのアクションを正常に実行できました。ただし、これをWebアプリケーションにしたいので、Djangoフレームワークの使用を開始しました。 私は多くの検索を行いましたが、すべてのロジックを含むこのPythonファイルをどこに正確に配置すべきかをまだ理解できていません。別のクラスベースのファイルが(logic.py)あり、それを呼び出す必要がありview.pyますか？グーグルで調べたところ、多くの開発者がDjangoのmodels.pyにビジネスロジックを配置していることがわかりました。ただし、モデルはバックエンドと排他的に通信する必要があるため、直感的には正しくないと感じています。助けていただければ幸いです。事前に感謝します。

26 python  django  templates  business-logic  view 

Rails 3.1.0アプリケーションのパフォーマンスに問題があり、ARでクエリのドームを変更したため、ビューのレンダリングに時間がかかりすぎ、ビュー、ループなどを分割した多くのパーシャルでビュー内および他のパーシャル内で動的にレンダリングされます。 それで、多数のパーシャルを持つのは悪い習慣ですか？ ビューのレンダリング時間を改善するために、パーシャルの数を減らす必要がありますか？ ありがとう

16 ruby-on-rails  view  rendering 

4 + 1アーキテクチャビューモデルがUMLにどのようにマッピングされるかについて、少し混乱しています。 ウィキペディアは次のマッピングを提供します。 論理ビュー：クラス図、コミュニケーション図、シーケンス図。 開発ビュー：コンポーネント図、パッケージ図 プロセスビュー：アクティビティ図 物理ビュー：展開図 シナリオ：ユースケース図 「オブジェクトライフサイクルコンセプトにおけるUMLシーケンス図の構造の役割」というペーパーは、次のマッピングを提供します。 論理ビュー（クラス図（CD）、オブジェクト図（OD）、シーケンス図（SD）、コラボレーション図（COD）、状態図図（SCD）、アクティビティ図（AD）） 開発ビュー（パッケージ図、コンポーネント図）、 プロセスビュー（ユースケース図、CD、OD、SD、COD、SCD、AD）、 物理ビュー（展開図）、および 上記の4つを組み合わせたユースケースビュー（ユースケース図、OD、SD、COD、SCD、AD）。 WebページUML 4 + 1 View Materialsは、次のマッピングを提示します。 最後に、ホワイトペーパー「UML 2で4 + 1ビューアーキテクチャを適用する」では、さらに別のマッピングを提供しています。 論理ビュークラス図、オブジェクト図、状態図、複合構造 プロセスビューシーケンス図、コミュニケーション図、アクティビティ図、タイミング図、相互作用概要図 開発ビューのコンポーネント図 物理ビュー展開図 ユースケースビュー、ユースケース図、アクティビティ図 さらに検索すると、他のマッピングも明らかになると確信しています。 通常、さまざまな人々が異なる視点を持っていますが、ここでなぜそうなのかわかりません。特に、各UML図は、特定の側面からシステムを説明しています。それで、例えば、なぜ「シーケンス図」はある著者によってシステムの「論理的見解」を記述すると見なされ、別の著者は「プロセス図」を記述すると見なされるのでしょうか？ 混乱を明確にするのを手伝ってもらえますか？

15 architecture  uml  model  view 

彼の本「Clean Architecture」で、叔父ボブは、プレゼンターが受け取ったデータを「表示モデル」と呼ぶものに入れるべきだと言っています。 これは、Model-View-ViewModel（MVVM）設計パターンの「ViewModel」と同じものですか、それとも単純なデータ転送オブジェクト（DTO）ですか？ 単純なDTO ではない場合、ビューにどのように関連しますか？ビューは、オブザーバー関係を通じて更新されますか？ 私の推測では、彼の本の第23章でロバート・マーティンは次のように述べているため、MVVMのViewModelに似ていると思います。 [The Presenter's]ジョブは、アプリケーションからデータを受け取り、プレゼンテーション用にフォーマットして、Viewがデータを画面に簡単に移動できるようにすることです。たとえば、アプリケーションでフィールドに日付を表​​示する場合、プレゼンターにDateオブジェクトを渡します。プレゼンターは、そのデータを適切な文字列にフォーマットし、Viewモデルと呼ばれる単純なデータ構造に配置します。Viewモデルでは、データを見つけることができます。 これは、たとえばDTOの場合のように、単に関数引数として受け取るのではなく、Viewが何らかの方法でViewModelに接続されていることを意味します。 あなたは、画像を見れば、プレゼンターはビューモデルを使用しますが、ので、私はこれを考えるもう一つの理由はありませんビューを。一方、プレゼンターは出力境界と出力データDTOの両方を使用します。 DTOでもMVVMのViewModelでもない場合は、それが何であるかを詳しく説明してください。

13 architecture  mvvm  dto  plugin-architecture  view 

WPFのpythonラッパーとDAGサポートを使用して、pythonでアプリケーションを構築しています。私は現在、データとビューの間でやり取りする一貫した方法を決定する必要があるところにいます。 私が見る限り、現在2つの明白な解決策があります。 1つ目は、Androidアプリケーションの構造に似ています。ビューを設定/移入するコントローラーがあります。したがって、コントローラーはビューを所有し、表示されるプリミティブデータのみをプッシュします。ビューは単なるダム層であり、何が起こっているのか、そのデータがどこから来ているのかはわかりません。そして、ユーザーがビューを操作すると、コントローラーにコールバックが送信されます（登録されている場合）。 UserInfoController.py userInfoView = UserInfoView() userInfoView.onGenderChangedCallback = self.onGenderChangedCallback userInfoView.setUserGenderValue(user.getGender()) UserInfoView.py def setUserGenderValue(self, gender): self.userGender = gender def getView(self): return ui.Label(self.userGender, onEditCallback=self.onGenderChangedCallback) 2つ目は、モデルの（参照）をビューに渡し、ビューにデータを取得および更新させることです。ビューにはモデルが含まれているため、コントローラへの追加のコールバックなしでモデルを更新できます。 UserInfoViewModel.py self.gender = 'Male' UserInfoView.py def getView(self): return ui.Label(self.ViewModel().getGender(), onEdited=self.genderEdited) def genderEdited(self, newValue): self.ViewModel().setGender(newValue) だから私が求めているのは、非常に原始的なデータを渡してビューをできるだけ一般的なものにして、コールバックを操作してコントローラーでビジネス固有の処理を行うべきかどうかです。 または、モデル全体をビューに渡して、ビューでモデルを直接更新できるようにする必要があります。つまり、入力するコードが少なくなります。 PS。コードを判断しないでください-それは単に視覚化のためです。 編集： また追加する -このアプリケーションは、ダックタイピングをサポートするpythonで記述されます。つまり、2番目のアプローチでは、モデルが必要なインターフェースを満たす限り、ビューは再利用可能です。

10 model  view