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

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 一般的に、ソフトウェアを設計するとき、どのような最適化を一般的に好みますか？ あなたのデザインを最適化することを好むタイプですか 開発時間（つまり、書くのが迅速で、保守が簡単） 処理時間 ストレージ（RAM、DB、ディスクなど）スペース もちろん、これは解決される問題のタイプと関係する締め切りに対して非常に主観的であるため、ある形式の最適化を別の形式よりも選択する理由についてお聞きしたいと思います。

19 design  optimization 

私は私が移動する方が良いだろう（もしあれば）どのような状況では、コードとEntity Frameworkののメイク使用されているすべての私のビジネス・ロジックを、持っている場合は、いくつかのストアドプロシージャにビジネスロジックを、代わりのコードでそれをすべて保ちますか？ 明確にするために、代わりにではなく、現在のセットアップ（コード内のビジネスロジック）と組み合わせて意味します。ストアドプロシージャですべてのビジネスロジックを使用することの長所と短所を求めている同様の質問を多数見ましたが、ビジネスロジックの残りを保持しながら、エッジケースロジックでストアドプロシージャを控えめに使用することについてはあまり知りませんでしたコードで。 違いがある場合は、MSSQLとEntity Frameworkを使用しています。 これらは、以前にストアドプロシージャを使用したことがある状況です。 実行に数分かかっていた複雑なレポート（これはWebアプリのページでした）。LINQが提供するものよりもはるかに効率的な（実行に数秒しかかからない）SQLを作成できることがわかりました。 Webアプリケーションは、アプリケーションに関係のない他の多くの機密情報を含む別のデータベースのいくつかのテーブルを読み書きする必要がありました。すべてにアクセスするのではなく、必要なことだけを行い、限られた情報のみを返すストアドプロシージャを使用しました。Webアプリケーションは、テーブルなどにアクセスせずに、このストアドプロシージャのみにアクセスできます。 この質問をする前に私が見た他の投稿： ストアドプロシージャは、世界最大のITソフトウェアコンサルティング会社の1つで悪い習慣ですか？ Webアプリケーションのストアドプロシージャにすべてのビジネスロジックを保持することの長所と短所 /programming/15142/what-are-the-pros-and-cons-to-keeping-sql-in-stored-procs-versus-code /dba/2450/what-are-the-arguments-against-or-for-putting-application-logic-in-the-database/2452#2452 ORMを使用せず、ストアドプロシージャを使用する場合

19 design  sql-server  orm  business-logic  stored-procedures 

何かに気付いたばかりで、その理由はあるのでしょうか。C ++（std :: priority_queueは最大ヒープ）を除いて、最大ヒープを提供する他の言語は知りません。 Pythonのheapqモジュールは、リストの上にバイナリの最小ヒープを実装します。 Javaのライブラリには、min-priority-queueを実装するPriorityQueueクラスが含まれています。 Goのライブラリには、互換性のあるデータ構造の上に最小ヒープを実装するコンテナ/ヒープモジュールが含まれています。 AppleのCore Foundationフレームワークには、最小ヒープを実装するCFBinaryHeap構造が含まれています。 最大ヒープは最小ヒープよりも直感的であり、技術的には実装の違いは比較演算子を変更するだけの問題だと思います。本当の理由はありますか？ほとんどのアプリケーションでは、最大ヒープではなく最小ヒープが必要ですか？前もって感謝します

19 design  algorithms 

2人の顧客が在庫が1品目のみの製品を同時に追加する場合を管理するためのベストプラクティスは何ですか？ これら2人の顧客の1人が同じ製品を追加するのを避けるために、バスケットのコードにチェックが必要ですか？ または、このチェックは、たとえば、関連する製品がまだ在庫にあることを確認するための2番目のクエリ（同時顧客がまだ購入していないことを意味する）を行う際に、支払いフェーズで実行する必要がありますか？

18 design  concurrency  locks 

この投稿を改善したいですか？引用や回答が正しい理由の説明など、この質問に対する詳細な回答を提供します。十分な詳細のない回答は、編集または削除できます。 プログラムのデザインと動作の落書きをもっと合理化して、他の開発者と共通の言語にしたいです。 私はUMLを見て、原則としてそれが私が探しているもののようですが、それはやり過ぎのようです。私がオンラインで見つけた情報も非常に肥大化しており、学術的だと思われます。 UMLを同僚に説明するのに十分な英語の平易な方法で理解するにはどうすればよいですか？地上レベルでUMLを理解するための標準的なリソースは何ですか？

18 design  uml 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 私は現在、（C）で実際の経験がほとんどない言語での現在のプログラミング能力をはるかに超えるプロジェクトに着手するというアイデアをいじっています。全体的な設計を進めるために、私がよく知っている（Perl / Python / Ruby / C＃のような）高級言語でプロトタイプを作成することは価値があるでしょうか？ 最終的に、最終製品はパフォーマンスに敏感であるため（データベースエンジンです）、Cを選択しますが、Cをよく知らないと木のために森を失うことになるのではないかと思います。 同様の質問を探しているうちに、プログラマーがPrologでプロトタイプを作成し、それをアセンブラーで試していたという1人の仲間がいることに気付きました。

18 programming-languages  design  productivity  c  prototyping 

私はCSの学生です。現在、客観的な分析と設計を教えている講義に参加しています。ほとんどの場合、ユースケースの記述、クライアント用のアプリケーションを作成するときに直面する問題の分析、拡張可能で開発者にとって明確であり、クライアントがいくつかについて議論するときに問題が発生しないようにプロジェクトを設計する方法特徴。「客観的」なので、OOPの観点（クラスなど）から学習しています。 現在、ヘルパーツールとしてUMLを使用しています。私はOOPを十分に理解していると思いますが、機能的なパラダイムも学び、いくつかの小規模なプロジェクトでうまく使用しました。 私たちの先生は、「機能的なパラダイムについてはどうですか？」質問では、彼は関数型言語でより大きなプロジェクトをプログラミングしておらず、関数型プログラムがどのツールを使用しているのかを知りません。 それで、彼らは何を使うのでしょうか？このための方法論はありますか？それとも、そのようなことの必要はありませんか？

18 design  functional-programming  uml  modeling 

現在、多層アーキテクチャを使用して大規模なサブシステムをリファクタリングしており、効果的なエラーログ処理戦略の設計に苦労しています。 私のアーキテクチャは、次の3つのレイヤーで構成されているとしましょう。 パブリックインターフェイス（IE MVCコントローラー） ドメイン層 データアクセス層 私の混乱の原因は、エラーロギング\処理を実装する場所です。 最も簡単な解決策は、ログをトップレベル（IE Public Interface \ MVC Controller）に実装することです。しかし、これは間違っていると感じます。これは、異なるレイヤーを介して例外をバブリングし、ログに記録することを意味するためです。そのソースで例外をログに記録するのではなく。 私が最も多くの情報を持っているので、そのソースで例外をログに記録することは明らかに最適なソリューションです。これに関する私の問題は、すべての例外をキャッチせずにソースですべての例外をキャッチできないことであり、ドメイン/パブリックインターフェイスレイヤーでは、これはすでに下のレイヤーでキャッチされ、ログに記録され、再スローされた例外をキャッチすることになります。 もう1つの可能な戦略は、＃1と＃2の組み合わせです。これにより、スローされる可能性が最も高いレイヤーで特定の例外をキャッチし（SqlExceptionsつまり、データアクセスレイヤーでキャッチ、ロギング、再スロー）、トップレベルでキャッチされなかった例外をログに記録します。しかし、これはまた、すでにログに記録されたエラーと処理されていないエラーを区別できないため、トップレベルですべての例外をキャッチして再ログする必要があります。 さて、これは明らかにほとんどのソフトウェアアプリケーションの問題であるため、例外がソースで捕捉され、一度ログに記録されるこの問題の標準的な解決策が必要です。しかし、自分でこれを行う方法がわかりません。 この質問のタイトルは「多層アプリケーションでの例外のロギング」に非常に似ていますが、その投稿の回答には詳細が欠けており、私の質問に答えるには不十分です。

17 design  error-handling 

私は物理エンジンを作成していますが、全体を把握するのが非常に難しくなっています。多くの場合、休憩後にコードに戻ると、なぜそれが機能しないのか覚えていません。ほとんどの問題は、単純なプログラミングの間違いではなく、物理エンジンの設計上の欠陥です。そのため、プログラミングする前に設計を終了する必要があります。 ただし、物理エンジンの設計全体を紙に書く方法が必要です。さもなければ、明日それを忘れて再び失われます。UMLクラス図は、物理エンジンの設計にはまったく適していません。私はクラスではなくプロセスについて本当に気にします。プロセスの単一ステップ（フレーム）をモデル化しても、多くのステップでのエンジンの最終的な動作を理解するのに役立たないため、ビジネスプロセス図は本当に便利だとは思いません。 したがって、プロセスを追跡するためにどのような図を使用する必要がありますか？物理エンジンを作成するためにどのようなダイアグラムの専門家が使用しますか？

17 design  diagrams  physics 

ユーザー認証にJWTトークンを使用するRESTful APIを構築しています（loginエンドポイントによって発行され、その後すべてのヘッダーで送信されます）。一定時間後にトークンを更新する必要がありrenewます（エンドポイントを呼び出して、更新されたトークンを返します） ）。 トークンの有効期限が切れる前にユーザーのAPIセッションが無効になる可能性があるため、エンドポイントはすべて、1）トークンがまだ有効で、2）ユーザーのセッションがまだ有効であることを確認することから開始します。クライアントがトークンをローカルに保存するため、トークンを直接無効にする方法はありません。 したがって、すべてのエンドポイントは、クライアントに次の2つの条件を通知する必要があります。1）トークンを更新する時間、または2）セッションが無効になり、システムへのアクセスが許可されなくなったこと。2つの条件のいずれかが発生したときにクライアントに信号を送るエンドポイントの2つの代替案を考えることができます（クライアントがいずれかのオプションに適応できると仮定します）： セッションが無効になった場合はHTTP 401コード（無許可）を返し、トークンの有効期限が切れてrenewエンドポイントを呼び出すときは412コード（前提条件失敗）を返します。これにより200（ok）コードが返されます。 セッションが無効であるか、トークンの有効期限が切れていることを通知するために401を返します。この場合、クライアントはすぐにrenewエンドポイントを呼び出し、200を返すとトークンが更新されますが、renew401も返す場合は、クライアントがシステム外にあることを意味します。 上記の2つの選択肢のうち、どちらをお勧めしますか？どちらがより標準的で、理解しやすく、そして/またはよりRESTfulでしょうか？または、まったく別のアプローチをお勧めしますか？どちらのオプションにも明らかな問題やセキュリティ上のリスクがありますか？回答にあなたの意見を裏付ける外部参照が含まれている場合の追加ポイント。 更新 皆さん、本当の質問に焦点を合わせてください- 更新/セッションの無効化を通知するための2つのHTTPコードの選択肢のうち、どちらが最適ですか？私のシステムがJWT とサーバーサイドセッションを使用しているという事実を気にしないでください、それは非常に特定のビジネスルールのための私のAPIの特性であり、私が助けを求めている部分ではありません;）

17 design  rest  web-services  http  authentication 

私はデスクトップアプリケーションを開発しており、このアプリケーションを実行するにはいくつかの情報が必要ですが、この情報は変更されません（アプリの実行ごとにデータを読み込む必要がありますが、データは変更されません）。データは、アプリを実行しているコンピューターと同じコンピューターに保存する必要があります（クライアント側のストレージ？）。 また、ユーザーがこの情報を簡単に変更できない場合も優れています（ITの知識があまりないと仮定します）。 この種の情報はどのように保存すればよいですか？ローカルデータベース？アプリケーションと共に送信されるXML WPFを使用しています。

17 c#  design  data  wpf 

四半世紀前に私がC ++を学んでいたとき、インターフェースは寛容であるべきだと教えられました。消費者は代わりにソースやドキュメントにアクセスできないかもしれないので、メソッドが呼び出される順番を気にしないでくださいこの。 しかし、私がジュニアプログラマーや上級開発者を指導したときはいつでも、彼らは驚いたことに反応し、これは本当にこれが本当のことなのか、それとも流行から外れたのかと疑問に思いました。 泥のように明確ですか？ これらのメソッド（データファイルを作成するための）とのインターフェイスを検討してください。 OpenFile SetHeaderString WriteDataLine SetTrailerString CloseFile もちろん、これらを順番に実行することもできますが、ファイル名（考えてみてくださいa.out）や、含まれているヘッダーとトレーラーの文字列については気にしないと言って、単に呼び出すことができますAddDataLine。 それほど極端ではない例として、ヘッダーとトレーラーを省略する場合があります。 さらに、ファイルを開く前にヘッダーとトレーラーの文字列を設定することもできます。 これは認識されているインターフェイス設計の原則ですか、それとも名前が与えられる前のPOLAの方法ですか？ NBは、このインターフェイスの詳細に動揺することはありません。これは、この質問のための単なる例です。

17 design  design-patterns  interfaces 

Event Sourcingの設計に出会い、RESTクライアントが必要なアプリケーションで使用したいと思います（正確にはRESTfulです）。ただし、RESTは非常にCRUDに似ており、イベントソーシングはタスクベースであるため、これらを接続することはできません。RESTサーバーへの要求に基づいてコマンドの作成をどのように設計できるのか疑問に思いました。この例を考えてみましょう： RESTを使用すると、Fileというリソースに新しい状態を設定できます。1つのリクエストで、新しいファイル名を送信したり、親フォルダーを変更したり、ファイルの所有者を変更したりできます。 イベントソーシングを使用できるようにサーバーを構築する方法。私はこれらの可能性について考えていました： フィールドが変更されたサーバ上で決定し、適切なコマンドを作成する（RenameFileCommand、MoveFileCommand、ChangeOwnerCommand、...）と個別にこれらを派遣。ただし、このセットアップでは、各コマンドが失敗し、他のリソースがトランザクションから除外され、リソースへの「アトミックな」変更から除外されます。 発送のみ一つのコマンド（UpdateFileCommand）およびコマンドハンドラでは、より正確に集計では、変更されたフィールドを決定し、代わりに個々のイベントを送信します（FileRenamedEvent、FileMovedEvent、OwnerChangedEvent、...） これはまったく好きではありません：サーバーへのリクエストでは、ヘッダーで使用するコマンドを指定します。UIはまだタスクベースです（ただし、通信はRESTを介して行われます）。ただし、REST通信のその他の使用（外部アプリなど）では失敗します。1つのリクエストで1つのフィールドのみを変更するようにバインドされているためです。また、UI、REST、およびESベースのバックエンドに非常に大きなカップリングをもたらします。 あなたはどちらを好むでしょうか、これを処理するより良い方法はありますか？ サイドノート：イベントソースのためにJavaとAxon Frameworkで書かれたアプリ。

17 design  rest  event-sourcing 

あると仮定nホットラインのためのラインは。 顧客がホットラインに電話をかけるたびに、コールはいずれかのn回線に転送されます。そして、n行のそれぞれに呼び出しの割合を割り当てたいと思います。2つの回線があり、1つの回線に60％が割り当てられ、もう1つの回線に40％が割り当てられていると仮定します。 各回線への呼び出しの割合は事前にわかっていますが、問題は、1日に受信される呼び出しの数がわからないことです。 総通話数を知らずに通話数を分配するにはどうすればよいですか？

17 design  algorithms 

TL; DR-最適なデータ構造を設計して、測定単位内の単位を定義しようとしています。 A Unit of measureは、本質的ににvalue関連付けられた（または数量）unitです。 SIユニットには7つのベースまたはディメンションがあります。すなわち：長さ、質量、時間、電流、温度、物質の量（モル）、および光度。 これは十分に簡単ですが、多くの派生ユニットと頻繁に使用するレートがあります。結合されたユニットの例はNewton：でkg * m / s^2あり、レートの例はですtons / hr。 暗黙のユニットに大きく依存するアプリケーションがあります。変数または列名に単位を埋め込みます。しかし、異なる単位で測定単位を指定する必要がある場合、これは問題を引き起こします。はい、入力および表示時に値を変換できますが、これにより、独自のクラス内にカプセル化する多くのオーバーヘッドコードが生成されます。 コードプレックスやその他の共同作業環境には多くのソリューションがあります。プロジェクトのライセンスは同意できますが、プロジェクト自体は通常、非常に軽量または重すぎます。「ちょうどいい」というユニコーンを追いかけています。 理想的には、次のようなものを使用して新しい測定単位を定義できます。 UOM myUom1 =新しいUOM（10、ボルト）; UOM myUom2 = new UOM（43.2、Newtons）; もちろん、クライアントのニーズに基づいて、ImperialユニットとSIユニットを組み合わせて使用​​します。 また、このユニットの構造を将来のデータベーステーブルと同期させて、データ内で同じ程度の一貫性を提供する必要があります。 測定単位クラスを作成するために使用する必要がある単位、派生単位、およびレートを定義する最良の方法は何ですか？1つ以上の列挙型を使用していることはわかりましたが、他の開発者にとってはイライラする可能性があります。単一の列挙型は200以上のエントリで巨大になりますが、複数の列挙型はSIと帝国のユニットに基づいて混乱し、ユニット自体の分類に基づいた追加の内訳があります。 私の懸念のいくつかを示す列挙型の例： myUnits.Volt myUnits.Newton myUnits.meter SIUnit.meter ImpUnit.foot DrvdUnit.Newton DrvdUnitSI.Newton DrvdUnitImp.FtLbs 使用中のユニットのセットはかなり明確に定義されており、有限のスペースです。クライアントから需要がある場合、新しい派生ユニットまたはレートを拡張および追加する機能が必要です。このプロジェクトはC＃で作成されていますが、より広範な設計の側面は複数の言語に適用できると思います。 私が調べたライブラリの1つでは、文字列を介したユニットの自由形式の入力が可能です。次に、UOMクラスは文字列を解析し、それに応じてスロットを割り当てました。このアプローチの課題は、正しい文字列形式が何であるかを開発者に考えさせ、記憶させることです。そして、コンストラクターで渡される文字列を検証するためにコード内に追加のチェックを追加しないと、ランタイムエラー/例外のリスクが発生します。 別のライブラリは、開発者が作業しなければならないクラスを本質的に多く作成しました。同等のUOMとともに、DerivedUnitなどRateUnitを提供しました。基本的に、コードは、私たちが解決しようとしている問題に対して非常に複雑でした。そのライブラリは基本的にany：anyの組み合わせ（ユニットの世界では合法です）を許可しますが、可能なすべての組み合わせを許可しないことで問題の範囲を広げることができます（コードを簡素化します）。 他のライブラリはとてつもなくシンプルで、たとえば演算子のオーバーロードも考慮していませんでした。 さらに、誤った変換（たとえば：ボルトからメートル）の試みについても心配していません。この時点でこのレベルでアクセスできるのは開発者だけであり、これらのタイプの間違いから保護する必要は必ずしもありません。

17 c#  design  naming  data-structures