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

Vモデルは、滝の下半分が上に曲がってVを形成しているウォーターフォールモデルに過ぎないようです。新しいものを追加する方法がわかりません。 図から、私もフローを理解していません。すべての方向を指す矢印があり、最初に来るものを理解できません。Vを左上から下の中央まで、続いて右上まで戻ってきますか？または、アイテムが低くなる前にすべてを高くしてVを下に進めますか？ インターネットには、このモデルの十分な説明がありません。誰かがそれを本当のStackExchange形式で説明できたら素晴らしいでしょう:)

19 development-process  model  waterfall  engineering 

ソリューションに次のレイヤーがあります。 App.Domain App.Service App.Core（これをApp.DataLayerと呼ぶかもしれません） App.Web ソフトウェア設計パターンは私の質問ではなく、次のモデルがあります Domain public class Foo { public int Id {get;set;} public int Name {get;set;} public int Value {get;set;} } ビュー（たとえば、ホームページ）でこのモデルを使用しId, Name & Value、さらにを使用したいので、ViewModelを作成する場合は、次を追加します。 public class FooViewModel { public int Id {get;set;} public int Name {get;set;} public int Value {get;set;} } だから、それは良いアイデアですか？または単に？のFoo代わりに使用しFooViewModelます

16 asp.net-mvc  model 

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 

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

15 mvc  model  service 

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