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

ドメインモデルがあり、それを永続化レイヤーから読み取って保存したいとしましょう-現在のところ、それはjsonファイルの可能性がありますが、将来的にはxmlまたはデータベース（タイプも変更される可能性があります）になる可能性があります）。 永続化レイヤーからドメインモデルを生成するために、たとえばgetAll()とsaveAll()メソッドを含む簡単なインターフェイスの実装を用意しました。別のタイプの永続化に切り替えたい場合は、インターフェースの実装を変更するだけです。ただし、実装内では、完全に異なるソリューションを使用してデータを読み取り、保存するため、他のライブラリの異なるオブジェクトを使用してデータを処理する必要があります。 最初の実装でJsonシリアライザーを使用するとします。次に、そのシリアライザーのインスタンスを私の実装で直接インスタンス化します。これは、そのシリアライザに依存する私の実装に直接つながります。別のシリアライザを与えることはできません。しかし、シリアライザ（またはあらゆる種類の永続化）のユニバーサルインターフェイスがないため、これはいずれにしても不可能です。したがって、別のシリアライザを使用したい場合、私ができる唯一のことは、外部から別のシリアライザを渡すのではなく、完全に新しい実装を記述することです。 この場合、依存関係をハードコードしても大丈夫ですか？またはより良いオプションはありますか？

8 java  dependencies  persistence 

3〜4つの相互依存プログラムを開発しています。それらをfoo bar bazとauthと呼びます。お互いに独立してほしいです。各プログラムを他社にライセンス供与する場合を想像してみてください。fooとbarが必要な企業もあれば、bazだけが必要な企業もあります。authを独立しておくことも良い方法のようです。 コンテキスト：authはすべてのシステムの認証を処理します。authのメインのusersテーブルには、user_id、email、password、first、lastがあります fooには、アプリケーションの特定のフィールド（user_id、role_idなど）を持つusersテーブルもあります。 各システムには独自のデータベースがあります。過去に、各アプリケーションから認証データベースへの外部キーを作成しました。他のデータベースから更新権限を削除しましたが、特定の関連フィールドへの選択アクセスを許可しました。これは緊密な依存関係を作成するため、悪い解決策のように見えますが、ユーザー名と電子メールをfoo、bar、またはbazデータベースに格納する必要がないように、dbを正規化することができました。 すべてのデータベースに情報を保存する方が良いでしょうか？または、認証IDをfoo barとbazに保存し、apiを使用してauthIdを使用してユーザー情報を取得する方が良いでしょうか？ 同様に、3つのシステムすべてに顧客がいる可能性があります。確かに、auth dbに依存関係を作成するのは悪いようですが、3つすべての顧客のdbについてはどうですか？ または、1つの中央データベースを作成するのに最適なソリューションです。1つのユーザーテーブル。 他の提案？

8 architecture  web-development  dependencies  normalization 

複数の保険商品の申し込みフォームとして使用するWebアプリケーションを作成する必要があります（合計15）。このアプリケーションフォームはフォームウィザードに似ています。4〜10の製品に応じて、複数のページにまたがります。 フォームがレンダリングするすべてのさまざまな要素（入力、選択ボックス）の合計は約250ですが、最も複雑な製品でさえ170を超えることはありません。最も複雑でないものでも約80の要素が必要です。 製品ごとに1つずつ、15の異なるアプリケーションフォームを作成するのではなく、すべての製品で使用される単一のアプリケーションフォームを作成する必要があります。 想像できるように、要素には要素間に多くの依存関係があります。フィールドに値を入力すると、別のフィールドまたはフィールドのセットが（現在のページまたは次のページで）表示または非表示になります。入力した値に基づくその他の依存関係： 要素の値が必要かどうか 選択ボックスの可能な値が変更されます 検証制約が変更されます ご想像のとおり、これのモデリングは非常に複雑です。問題は、これらすべての要素のモデリング（および文書化）、それらの間の依存関係、および検証制約にどのツールを推奨するかです。どのようにモデリングしますか？この場合、データモデルについてはまったく触れません。このモデルは、必要な作業の仕様の一部となり、プロジェクトの完了後の参考になります。モデルを変更しても、申請書は自動的に変更されません。 簡単にできることのいくつか： 特定の要素が依存する要素を確認する 特定の製品のフォームに含まれるすべての要素を確認する 特定の製品に必要な要素を確認する 各要素の検証ルールを定義する 各要素にさまざまな属性を定義する 制限：モデリングを行うのは製品マネージャーと製品所有者です。

8 web-applications  web  modeling  dependencies  forms 

私の研究の一環として、他人に配布する必要のないPythonおよびMATLABコードを多数記述しています。ソフトウェアを配布する必要がある場合でも、PythonとMATLABの両方が解釈されるため、共有が比較的簡単になります。 今、私はC ++で配布したいソフトウェアを書いています。私は自分のマシンでソフトウェアをコンパイルする方法を理解していますが、他の人にソフトウェアを提供するために何をする必要があるかを理解していません。 まず、プロジェクトの詳細：視覚化を計算して表示するためのコードを書いています。プロジェクトはグラフベースなので、LEMONグラフライブラリを使用しています。視覚化を表示する目的でVTKとOpenGLの実装を調査しています。私のソフトウェアを使用できるように、それらの環境のユーザー向けにPythonおよびMATLABバインディングを記述したいと思います。また、WindowsおよびLinuxバージョンを作成したいと思います（OS Xについてはまだ考えていません...）。 それでは、レモングラフライブラリを例に考えてみましょう。これは、小さな共有オブジェクトを伴う一連のヘッダーです。開発システムでは、CMakeを使用してライブラリをコンパイルし、プロジェクトにリンクします。 次に、Windowsで実行している誰かにソフトウェアを提供したいとします。私は彼らがインストーラーをダウンロードし、ボタンを1つか2つクリックして、すべての面倒を見てもらいたいと思っています。レモンライブラリやOpenGLのインストールについて心配してほしくありません。彼らは意図的に何かをコンパイルする必要はありません。これは可能ですか？ 私はそれを感じていますが、参照を検索するときに不足します。Windowsでバイナリをコンパイルすると、Windows OSを実行している誰にでもそのバイナリを配布できるはずだという漠然とした考えがあります。しかし、私が使用するライブラリはどうですか？Windowsでそれらを静的にリンクする必要があると思います。これで、依存関係の問題が解決されます。しかし、私の心の奥で、静的リンクは良い習慣ではないことを読んだことがあります（または、これはLinuxだけですか？） ご存知のように、私は少し迷っています。私は正しい方向に微調整し、何かを知っていたら読んだ参考文献をいただければ幸いです！

8 c++  libraries  software  dependencies  portability 

依存関係管理ソリューションを検討するに値するほど大きくなり始めている.NETプロジェクトがいくつかあるので、あるプロジェクトから別のプロジェクトにバイナリをコピーする必要はありません。これが私がこれまでに見つけたものです： NPandayはMavenのポートに基づいています。最近どのように取り組んだかはわかりませんが、最後のリリースは2011年5月でした。 NuGetは活発に開発中であるようで、Microsoftから直接サポートされているようです。「依存関係の解決にのみ対処する」と不満を言う人もいますが、それ以外に何を対処すべきか、またはそれ以降に機能が追加されたかどうかはわかりません。最近、ビルドプロセスの一部としてバイナリをインポートする機能が追加されたようです。そのため、リポジトリにコミットする必要はありません。 2011年9月以降、何の注意も払われていないため、Refixはまだベータ版のようです。 これらの依存関係管理ツール（またはうまく機能する他のツール）を使用した最近の経験を持つ誰かがあなたの経験を共有しますか？NuGetは依存関係管理にそれを使用するのに十分成熟していますか？そうでない場合、何が不足していますか？

8 .net  dependencies  dependency-management