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

私は長い質問に謝罪します、それは少し暴言として読みますが、そうではないと約束します！私の質問を以下にまとめました MVCの世界では、物事は簡単です。モデルには状態があり、ビューにはモデルが表示され、コントローラーはモデルとのやり取り（基本的に）を行い、コントローラーには状態がありません。作業を行うために、コントローラーはWebサービス、リポジトリー、その他多くに依存しています。コントローラーをインスタンス化するとき、これらの依存関係を提供することに関心があります。アクション（コントローラーのメソッド）を実行するとき、これらの依存関係を使用してモデルを取得または更新するか、他のドメインサービスを呼び出します。一部のユーザーが特定のアイテムの詳細を表示する場合など、コンテキストがある場合、そのアイテムのIDをパラメーターとしてアクションに渡します。コントローラーのどこにも、状態への参照はありません。ここまでは順調ですね。 MVVMと入力します。WPFが大好きで、データバインディングが大好きです。ViewModelsへのデータバインディングをさらに簡単にするフレームワークが大好きです（Caliburn Micro atmを使用）。しかし、この世界では物事はそれほど簡単ではないと感じています。もう一度練習してみましょう。モデルには状態があり、ビューには ViewModel が表示され、ViewModelには（基本的に）モデルとのやり取りがあり、ViewModelには状態があります。するには、（1つ以上のモデルに、多分それ委譲し、すべてのプロパティを、それ手段は、それ自体の状態をあるモデルの1の方法または別の、への参照を持っている必要があります明確にするために）行いますViewModelには、Webサービス、リポジトリ、その他多くの依存関係があります。ViewModelをインスタンス化するとき、それらの依存関係だけでなく状態も指定する必要があります。そして、これは、紳士gentle女の皆さん、私をいらいらさせます。 あなたはインスタンス化する必要があるときProductDetailsViewModelからProductSearchViewModel（そこからあなたが呼び出されるProductSearchWebService順番に返されIEnumerable<ProductDTO>、あなたはこれらの事の1行うことができますか？私と一緒に、まだ、誰も）： call new ProductDetailsViewModel(productDTO, _shoppingCartWebService /* dependcy */);、これは悪いです、さらに3つの依存関係を想像してください。これは、ProductSearchViewModelそれらの依存関係も同様に引き受ける必要があることを意味します。また、コンストラクタを変更するのは苦痛です。 call _myInjectedProductDetailsViewModelFactory.Create().Initialize(productDTO);、ファクトリは単なるFuncであり、ほとんどのIoCフレームワークによって簡単に生成されます。Initメソッドは漏れやすい抽象化であるため、これは悪いと思います。また、Initメソッドで設定されているフィールドにreadonlyキーワードを使用することもできません。他にもいくつかの理由があると思います。 call _myInjectedProductDetailsViewModelAbstractFactory.Create(productDTO);So ...これは、このタイプの問題に通常推奨されるパターン（抽象ファクトリー）です。でも、実際に使い始めるまでは、静的型付けへの渇望を満たすため、天才でした。定型コードの量は多すぎると思います（私が使用するとんでもない変数名は別として）。ランタイムパラメーターを必要とする各ViewModelについて、2つの追加ファイル（ファクトリーインターフェースと実装）を取得し、4回の追加時間などの非ランタイム依存関係を入力する必要があります。また、依存関係が変更されるたびに、ファクトリーでも依存関係を変更できます。私はもうDIコンテナさえ使用していないように感じます。（Castle Windsorにはこれに対する何らかの解決策があると思います（それ自体の欠点があるため、間違っている場合は修正してください））。 匿名型または辞書で何かをする。私は静的型付けが好きです。 ええ このように状態と動作を混在させると、MVCにはまったく存在しない問題が発生します。そして、私は現在、この問題に対して本当に適切な解決策がないと感じています。今、私はいくつかのことを観察したいと思います： 人々は実際にMVVMを使用しています。したがって、彼らは上記のすべてを気にしないか、他の素晴らしい解決策を持っています。 WPFを使用したMVVMの詳細な例は見つかりませんでした。たとえば、NDDDサンプルプロジェクトは、DDDの概念を理解するのに非常に役立ちました。誰かがMVVM / WPFの似たような方向性を教えてくれたら、とても気に入っています。 MVVMをすべて間違っているのかもしれませんが、デザインを上下逆にする必要があります。たぶん、私はこの問題を全く抱えるべきではないでしょう。他の人が同じ質問をしているのは知っているので、私だけではないと思います。 要約する ViewModelが状態と動作の両方の統合ポイントであることは、MVVMパターン全体のいくつかの問題の原因であると結論付けるのは正しいですか？ 静的に型付けされた方法でViewModelをインスタンス化するための唯一/​​最良の方法は、抽象ファクトリパターンを使用していますか？ 詳細なリファレンス実装のようなものはありますか？ 状態/動作の両方を備えたViewModelがたくさんあるのは、デザインの匂いですか？

17 c#  design  wpf  mvvm 

Linq To SQLをラップするデータレイヤーがあります。このデータレイヤーには、このメソッドがあります（簡略化されています） int InsertReport(Report report) { db.Reports.InsertOnSubmit(report); db.SubmitChanges(); return report.ID; } 変更を送信すると、レポートIDがデータベース内の値で更新され、その値が返されます。 呼び出し側からは、次のようになります（簡略化） var report = new Report(); DataLayer.InsertReport(report); // Do something with report.ID コードを見ると、IDはInsertReport関数内で一種の副作用として設定されているため、戻り値を無視しています。 私の質問は、副作用に頼って、代わりにこのようなことをするべきかということです。 void InsertReport(Report report) { db.Reports.InsertOnSubmit(report); db.SubmitChanges(); } またはそれを防ぐ必要があります int InsertReport(Report report) { var newReport = report.Clone(); db.Reports.InsertOnSubmit(newReport); db.SubmitChanges(); return newReport.ID; } たぶん Report …

17 design  code-quality  code-smell 

ウィリアムクックはツイートで次のように書いています。 「UMLはMDDにとって最悪の事態です。幸いなことに、多くの人々がこれを認識しています...」 私はその主張の背後にある理由を知りたい（明らかに、彼の個人的な意見に言及していない）。 私は、世の中の多くの人々がUMLをそれほど好きではないことに気付きました。また、UMLが効果的な設計とモデリングの聖杯である学界にいることを言及する価値があります。

17 design  uml  mdd 

私の同僚は、ファクトリクラスを使用して、ASP.NET MVCソリューションでビューモデルオブジェクトを作成することを提案しました。ビューモデルがアプリで構築される方法の設計と保守性に役立つという考えです。 他の誰かがこの経験を持っているかどうかを知りたかった。私はいくつかの研究を行ったが、この実践についてはほとんど発見しなかった。 現在、コントローラレベルでビューモデルオブジェクトを作成しています。 public ActionResult Index() { return this.View(this.BuildIndexViewModel()); } したがって、this.BuildIndexViewModel（）は、viewmodelクラス（明らかに:)の作成を担当します。しかし、次の可能性を検討しています。 public ActionResult Index() { return this.View(ViewModelFactory.CreateIndexViewModel()); } これは面白いアイデアですが、私は100％確信していません。これについて他の人の意見に興味がありました。

17 design  asp.net-mvc 

オープンソースのECMとやり取りするために、新しいフレームワークの設計と開発を開始する必要があります。これには、このECMと対話するWebサイト開発者を支援するカスタマイズされたデータモデルが含まれているため、ノード操作の詳細やその他の低レベルの詳細を気にする必要はありません。これは、開発するクラスとメソッドの集まりです。 そのプロジェクトの組織と管理をどのように扱うかについて、いくつかの疑問があります。従うべき一般的なルール、ヒント、ベストプラクティス、またはこの種のプロジェクトを開発する際に留意すべき点はありますか？ フレームワークまたはライブラリの開発とアプリケーションの開発には多少の違いがあると確信しています。

17 design  project-management 

アプリケーションの視覚状態の25の画面のモックアップが提供されたとします。これは、完成したアプリケーションとして開発し、元の利害関係者または顧客に渡すことができると確信するのに十分であり、満足することを期待しています。当然のことながら、UIを思い付くために使用された多くの質問を関係者に繰り返し求めることになりますが、これは無駄です。 しかし、これは十分ではないことが何度もあります。アプリケーションを開発する過程で、インターフェイスを複製しているために要件が曖昧になり、最終的に顧客が最初に思ったほど満足していませんUIを作成するためにすべての情報を要求したとき。 私は他に何を求めるべきか分からず、具体的になり、要件と全体的な目標の理解を求めましたが、私は何を求めるべきかわかりません。今始めたばかりの場合、UIに至るすべての情報を再ハッシュするのに多くの時間が無駄になり、この段階では、顧客が本来持っていた多くの重要な理由が失われます。 UIモックアップに基づいて要件をロックダウンできないことを人々に理解させるにはどうすればよいでしょうか？ エンドユーザー向けのアプリケーション開発タスクを適切に実行するために、理想的には何から始めますか？

17 design  specifications 

私はTDDの理論をほとんど理解していますが、どのように始めればよいのかわかりません。個人プロジェクトのユニットテストを書いて実現するために座っています。。。何をテストしているのかわかりません。どのオブジェクト、どの機能など 例えば、私たちの家族が雑用の割り当てを管理するのに役立つアプリを書きたいとしましょう。ここに私の頭の中にいくつかの質問があります：このアイデアから最初のテストに行くにはどうすればいいですか？始める前にどれくらい決める必要がありますか。また、テストの作成を開始した後、どれだけ把握する必要がありますか データをテキストファイルとデータベースのどちらに保存するかなどの決定はいつ行いますか？開始する前にユーザー受け入れテストを行う必要がありますか？UIを設計する必要がありますか？スペックが必要ですか？（これらの例の質問の少なくともいくつかがおそらく「灰色の領域」にあることを理解しています）。 最初の単体テストにたどり着くというタイトルの質問に加えて、サンプルプロジェクトのようなプロジェクトの最初の単体テストがどのように見えるかも例を示してください。

17 design  tdd 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 クライアントからプロジェクトの仕様を受け取ったとします。そして今、プロジェクトの開発を開始します。通常、最初のモジュール（通常はユーザー登録）から始めて、あるモジュールから次のモジュールに進みます。モジュールの動作を開始する直前に頭の中で計画するだけですが、その前に計画はありません。 ただし、仕様を検討し、コーディングする前にシステムがどのように機能するか、たとえば主要なコンポーネントは何か、それらはどのように相互作用するかなどを計画しておいた方が良いと思います。私が何を計画すべきか正確にはわからない。 私が何を求めているのかをよりよく理解するには、どのようにすればよいですか- a）プロジェクトをコンポーネントに分割し、 b）相互作用を計画します。たとえば、クラス図を作成したり、単体テストを作成したりする必要がありますか？ 何か案は？

17 project-management  design  self-improvement  planning  specifications 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 この時点では、オブジェクトの状態にパブリックフィールドを使用することは基本的に決してすべきではないというのは、Javaの正統性のようです。（必ずしも同意するわけではありませんが、それは私の質問とは関係ありません。）それを考えると、今日からJavaのパブリックフィールドが言語設計の誤り/欠陥であったことは明らかです。それとも、今日でも言語の有用かつ重要な部分であるという合理的な議論がありますか？ ありがとう！ 更新： C＃、Python、Groovyなどのよりエレガントなアプローチについて知っています。これらの例を直接探しているわけではありません。バンカーの奥深くにまだ誰かがいるのではないかと思っているだけで、公共の場がどれほど素晴らしいのか、大衆はただの羊なのかなどについてつぶやいています。 更新2：明らかに静的な最終公開フィールドは、公開定数を作成する標準的な方法です。オブジェクトの状態（不変の状態でさえ）にパブリックフィールドを使用することについてもっと言及していました。パブリックフィールドを定数ではなく、状態ではなく使用する必要があるという設計上の欠陥のように思えます。言語のルールは、ガイドラインではなく構文によって自然に実施されるべきです。

17 java  design  history  api  languages 

新しいプロジェクトを紹介したばかりの場合、その仕組みを理解するために最初に探すことは何ですか？ 最初にデザインを探しますか？デザインがある場合、その中で何を探しますか？クラス図または展開図またはシーケンス図または他の何か？ それとも、コードにまっすぐ行きますか？もしそうなら、異なるレイヤーがどのように相互作用するかをどのように理解しますか？

17 design  architecture 

私は間違いなくそうすべき ケースで100％乗っています、クライアント側とサーバー側の両方のデータ検証使用するます。 しかし、私が働いてきたフレームワークと環境では、私が見たアプローチは決して乾いたことはありませんでした。ほとんどの場合、計画やパターンはありません。検証はモデルの仕様に記述され、検証はビューのフォームに記述されます。（注：私の実際の経験のほとんどは、Rails、Sinatra、およびjQueryを使用したPHPに関するものです） それを熟考すると、検証のセット（モデル名、フィールド、条件など）が与えられると、必要なクライアント側とサーバー側の両方のマテリアルを生成できるジェネレーターを作成することは難しくないようです。あるいは、そのようなツールはサーバー側の検証（たとえば、validates ActiveRecordモデルのコード取得し、クライアント側の検証（フォームに適用されるjQueryプラグインなど）を生成できます。 明らかに、上記は単なる「このアイデアを思いついた」という考えであり、正式な提案ではありません。この種のことは、アイデアが思いついたときよりも確かに難しいです。 それで、データ検証のための「1回だけ書き込み、サーバーとクライアントで実行する」技術の設計にどのようにアプローチしますか？ 関連サブトピック：特定のフレームワークまたはクライアント/サーバーテクノロジーには、そのようなツールが存在しますか？1セットの検証のみを維持しようとする場合の大きな落とし穴や課題は何ですか？

17 design  validation  dry  client-server 

私は現在、より大きなソロプロジェクトに取り組んでおり、インスタンスを作成する理由がわからないクラスがいくつかあります。 たとえば、現在のダイスクラスはすべてのデータを静的に格納し、そのメソッドもすべて静的です。サイコロを転がして新しい値を取得したいときは、を使用するだけなので、初期化する必要はありませんDice.roll()。 私はこのような主な機能を1つだけ持っているいくつかの類似したクラスを持ち、すべてのイベントを担当する一種の「コントローラー」クラスで作業を開始しようとしています（プレイヤーが移動したとき、そうです）、このクラスでも同じ考えに従うことができることがわかりました。これらの特定のクラスに対して複数のオブジェクトを作成する予定はないので、それらを完全に静的にすることは悪い考えでしょうか？ Javaに関しては、これが「悪い習慣」と見なされるのかと思っていました。私が見たものから、コミュニティはこのトピックに関して一種の分裂のように思われますか？とにかく、私はこれに関するいくつかの議論が大好きだし、リソースへのリンクも素晴らしいでしょう！

16 java  design  design-patterns  object-oriented-design  static-access 

数年前の私を含む多くのIT担当者にとって、理想的なソフトウェア開発プロセスでは、コード行を記述する前に、多くのUMLダイアグラムを含む詳細な設計ドキュメントを作成する必要があります。（これはウォーターフォールモデルの説明のように見えますが、反復がより小さいことを除いて、アジャイルでも同じです。） 過去2、3年の間に、私は完全に考えを変えました。関連するテストケースを含む詳細な要件仕様は、絶対に不可欠であると私はまだ考えています。大規模なプロジェクトの場合、コーディングを開始する前に、アーキテクチャ全体の概要も必要になります。ただし、残りはすべてコードで可能な限り行う必要があります。理想的なケースでは、コード自体を除いてソフトウェア設計の説明はありません。 どのようにしてこの結論に達しましたか？以下にいくつかの引数を示します。 フィードバック 文書を書いたり、図を作成したりするツールはほとんどフィードバックを提供しません。はい、UMLダイアグラムの整合性チェックを行うモデリングツールがありますが、それらは制限されており、多くのオーバーヘッドが伴います。 フィードバックがなければ、エラーを認識して修正することは困難です。 コードを書くとすぐに、次のような多くのフィードバックが得られます。 コンパイラからのエラーと警告 静的コード分析結果 単体テスト エラーをすばやく認識して修正できます。 一貫性 コードがドキュメントと一致していることを確認するには、何度も確認する必要があります。頻繁な変更がある場合、コードとドキュメントの同期を保つのは困難です。 リファクタリング テキストの説明や図をリファクタリングするのは通常困難でエラーが発生しやすい一方で、コードをリファクタリングするための強力なツールとテクニックがあります。 この作業を行うための前提条件が1つあります。コードは読みやすく、理解しやすいものでなければなりません。これはおそらくAssembler、Basic、またはFortranでは達成できませんが、最新の言語（およびライブラリ）ははるかに表現力があります。 したがって、私の議論が有効であれば、ソフトウェア設計の仕様やドキュメントの軽量化や軽量化に向かう​​傾向があるはずです。この傾向の経験的証拠はありますか？

16 design  programming-languages  development-process  modeling 

このアイデアは、+、-、％などのファクト演算子に触発されており、1つまたは2つの引数が渡され、副作用がない関数と見なすことができます。私または他の誰かが、3つ以上の引数の受け渡しを停止し、戻り値を介してのみ機能する言語を作成すると仮定します。 a）そのような言語はコードを理解しやすくするでしょうか？ b）コードの流れはより明確になりますか？（より多くのステップを強制し、潜在的に少ない対話を「非表示」にします c）制限により、より複雑なプログラムでは言語が非常に大きくなりますか？ d）（ボーナス）賛否両論に関するその他のコメント 注意： 2つの決定を行う必要があります。1つ目は、main（）または同等の外部でのユーザー入力を許可するかどうか、および配列/構造体を渡すときに何が起こるかについてのルールです。たとえば、1つの関数で複数の値を追加したい場合、その関数を配列にまとめることで制限を回避できます。これは、配列または構造体がそれ自体と対話することを許可しないことで停止できます。これにより、たとえば、各数値をその位置に応じて異なる量で除算できます。

16 design  programming-languages  functional-programming  functions 

私はいつも「共通ライブラリ」が良いアイデアだと思っていました。つまり、いくつかの異なるアプリケーションでしばしば必要とされる共通の機能を含むライブラリを意味します。コードの重複/冗長性が少なくなります。 私は最近、これは実際には悪い考えであり、「アンチパターン」であると言ったほどの記事を見つけました（今は見つかりません）。 このアプローチには利点がありますが。バージョン管理と変更管理は、このライブラリを使用するアプリスイートの回帰テストを意味します。 私は、新しい（Golang）プロジェクトにちょっと不満を感じています。コードの重複排除は長年にわたって私に打ち込まれてきましたが、今回はそれを試してみるべきだと思います。 これを書いている間、私はこの「共通ライブラリ」アプローチがアーキテクチャのスキミングの結果であると考え始めていますか？おそらく私の設計にはもっと考えが必要ですか？ 考えを聞いて興味を持っています。

16 design  go