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

アジャイル開発では、ポリシーとアプリケーションロジックは永続化メソッドなどの詳細よりも重要であるため、最後に永続化の決定を下す必要があると誰かが説明してくれました。したがって、この方法の弱点が明らかになるまでフラットファイルなどのより単純な永続性から始めてから、リレーショナルデータベースなどを使用して永続性を変更することをお勧めします。 これは本当ですか、それともコンセプトを誤解しましたか？これはアジャイルチームが通常どのようにアプリケーションを構築するのですか？その理由は何ですか？また、このアプローチを採用すべきではないのはいつですか？

21 architecture  agile  database  persistence 

プロジェクトの構成を保存したい 画面サイズ スクリーン位置 フォルダーパス ユーザー設定など。 これらを保存できる標準的な場所は、構成値です。 登録 INIファイル 個人用ファイル（* .cfgなど） これらの場所からどのように選択しますか？また、それらのいずれかを使用することの長所と短所はありますか？

19 windows  microsoft  configuration-management  persistence 

最近、スタンフォードのCoreNLPを使用して自然言語処理（NLP）の実験を開始しましたが、テキストマイニングアプリケーションなどのNLP解析データを保存する標準的な方法にはどのようなものがありますか？ 面白いと思う方法の1つは、子を隣接リストとして保存し、再帰クエリをうまく利用することです（Postgresはこれをサポートしており、非常にうまく機能していることがわかりました）。 しかし、私は長年にわたってこの分野で働いている人々によって採用されてきた分析の種類に応じて、おそらくこれを行うための多くの標準的な方法があると思います。それでは、NLPで解析されたデータの標準的な永続化戦略とは何ですか？

12 database  parsing  persistence  natural-language-processing 

永続性無知は、単一の責任原則のアプリケーションです。実際には、ドメインオブジェクト（DO）に永続性に関連するコードを含めるべきではなく、ドメインロジックのみを含める必要があります。 a）これは、下位層（つまり、永続層）に接続するコードが、ビジネスロジック層の他のクラス（OC）のドメインモデルの外側にあることを意味すると思いますか？ b）の下で、私の仮定した場合）正しいこと、そしてDOたとえば、Customer、決してなどの方法が含まれていませんGetCustomersかGetCustomerByID？ c）a）およびb）の下での私の仮定が正しく、Customerドメインオブジェクトがそのプロパティの一部に遅延読み込みを使用すると仮定すると、ある時点でCustomer内部ロジックがOCに連絡し、次にOCが遅延データを取得する必要があります。しかし、遅延データを受け取るためにOCCustomerに連絡する必要がある場合、ドメインオブジェクトに永続性に関連するロジックが含まれていないことを主張することはできません。 ありがとうございました jkohlheppへの返信 1）クラスはビジネスロジック層に含まれているOrderProviderと思いCustomerProviderますか？ 2）b）の下での私の仮定が正しいというあなたの返事から集めますか？ 3） ...いくつかの非公開注文フィールドが入力されているか、それがヌルであるかを確認します。nullの場合... しかし、私が知る限り、ドメインコードがプライベートorderフィールドに入力されているかどうかを確認する必要があるとすぐに、もしそうでない場合はOrderProviderに問い合わせると、すでにPIの原則に違反していますか？！

12 design-patterns  domain-driven-design  domain-model  persistence 

私の考えでは、新しいJEEプロジェクトが開始されると（これらの技術が適用される場合）、人々はEJB 3ではなくSpring + Hibernateの組み合わせを使用することを好みます。 若手プログラマーにもアドバイスされているようです、EJBの代わりにそのために行くことているようです。 これは個人的な好みですか、それとも適切な理由がありますか？（たとえば、EJBまたは技術の肥大化に対するパフォーマンスの理由または学習曲線に対する不信を引き起こした以前のEJBバージョンによって作成された個人的な傷跡）？

12 java  spring  enterprise-development  hibernate  persistence 

私はドメイン駆動設計（DDD）の概念に飛び込んでいますが、特にドメインと永続性モデルの分離に関して、いくつかの原則が奇妙であることに気付きました。これが私の基本的な理解です： （機能セットを提供する）アプリケーション層のサービスは、その機能を実行するために必要なリポジトリからドメインオブジェクトを要求します。 このリポジトリの具体的な実装は、それが実装されたストレージからデータをフェッチします サービスは、ビジネスロジックをカプセル化するドメインオブジェクトに、その状態を変更する特定のタスクを実行するように指示します。 サービスは、変更されたドメインオブジェクトを永続化するようリポジトリに指示します。 リポジトリは、ドメインオブジェクトをストレージ内の対応する表現にマップする必要があります。 さて、上記の仮定を考えると、以下は厄介なようです： 広告2 :: ドメインモデルは、ドメインオブジェクト全体（すべてのフィールドと参照を含む）をロードしているように見えます。それを要求した関数には必要ない場合でもです。他のドメインオブジェクトが参照されている場合は、それらのドメインオブジェクトとそれらが参照しているすべてのオブジェクトを順にロードしない限り、完全にロードすることさえ不可能かもしれません。遅延読み込みが思い浮かびますが、これは、最初にリポジトリの責任であるドメインオブジェクトのクエリを開始することを意味します。 この問題を考えると、ドメインオブジェクトをロードする「正しい」方法には、各ユースケースに専用のロード関数があるようです。これらの専用関数は、それらが設計されたユースケースで必要なデータのみをロードします。ここで、ぎこちないことが出てきます。最初に、リポジトリの実装ごとにかなりの量のロード関数を維持する必要があり、ドメインオブジェクトはnull、フィールドを運ぶ不完全な状態になってしまいます。後者は、値がロードされなかった場合でも、それを要求した機能によって要求されるべきではないため、技術的には問題になりません。それでも厄介で潜在的な危険です。 広告3 :: ドメインオブジェクトは、リポジトリの概念がない場合、構築時に一意性の制約をどのように検証しますか？たとえばUser、一意の社会保障番号（指定されている）を使用して新しいを作成する場合、データベースに一意性制約が定義されている場合にのみ、リポジトリにオブジェクトの保存を要求すると、最も早い競合が発生します。それ以外の場合はUser、指定された社会保障でを探し、それが存在する場合は、新しいものを作成する前にエラーを報告できます。ただし、制約チェックはサービスに存在し、それらが属するドメインオブジェクトには存在しません。私はドメインオブジェクトが検証のために（注入された）リポジトリを使用することが非常によく許可されていることに気づきました。 広告5 .: 私は、ドメインオブジェクトのストレージバックエンドへのマッピングを、ドメインオブジェクトが基になるデータを直接変更するのと比較して、作業集約的なプロセスとして認識しています。もちろん、具体的なストレージ実装をドメインコードから切り離すことは、必須の前提条件です。しかし、それは確かにそのような高コストで来るのでしょうか？ ORMツールを使用してマッピングを行うオプションがあるようです。ただし、ORMの制限に従ってドメインモデルを設計する必要がある場合や、ドメインからインフラストラクチャレイヤーへの依存関係を導入する必要がある場合もあります（たとえば、ドメインオブジェクトでORMアノテーションを使用するなど）。また、私はORMがかなりの計算オーバーヘッドをもたらすことを読みました。 ORSQLのような概念がほとんど存在しないNoSQLデータベースの場合、ドメインモデルで変更されたプロパティをどのように追跡しますsave()か？ 編集：また、リポジトリがドメインオブジェクトの状態（つまり、各フィールドの値）にアクセスするためには、ドメインオブジェクトがカプセル化を解除する内部状態を明らかにする必要があります。 一般に： トランザクションロジックはどこに行きますか？これは確かに永続化に固有のものです。一部のストレージインフラストラクチャは、トランザクションをまったくサポートしない場合もあります（インメモリモックリポジトリなど）。 複数のオブジェクトを変更する一括操作の場合、オブジェクトのカプセル化された検証ロジックを通過するために、各オブジェクトを個別にロード、変更、および保存する必要がありますか？これは、データベースに対して単一のクエリを直接実行することとは対照的です。 このトピックについて、いくつかの説明をお願いします。私の仮定は正しいですか？そうでない場合、これらの問題に取り組む正しい方法は何ですか？

12 domain-driven-design  domain-model  persistence 

私はアーキテクチャで作業しています。Webクライアントおよびモバイルアプリ用のREST APIを提供する予定です。私はSpring（spring mvc、spring data jpaなど）を使用しています。ドメインモデルは、JPA仕様でコーディングされています。 クリーンアーキテクチャのいくつかの概念を適用しようとしています（https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html）。すべてではありません。これは、jpaドメインモデルを維持するためです。 レイヤーを通過する実際の流れは次のとおりです。 フロントエンド <-> APIサービス -> サービス -> リポジトリ -> DB フロントエンド：Webクライアント、モバイルアプリ APIサービス：Rest Controllers、ここではコンバーターとdtoと呼び出しサービスを使用しています サービス：実装とインターフェースし、ビジネスロジックを含みます リポジトリ：CRUD操作とおそらくいくつかのSQLクエリを含む自動実装（Spring Data JPAによって実行）とのリポジトリインターフェイス 私の疑問：サービスとリポジトリの間に追加のレイヤーを使用する必要がありますか？ 私はこの新しいフローを計画しています： フロントエンド <-> APIサービス -> サービス -> 永続性 -> リポジトリ -> DB なぜこの永続化レイヤーを使用するのですか？クリーンアーキテクチャの記事で述べているように、不可知論的永続性レイヤーにアクセスするサービス実装（ビジネスロジックまたはユースケース）が欲しいです。また、リポジトリの使用を停止する場合など、別の「データアクセス」パターンを使用する場合は、変更は必要ありません。 class ProductServiceImpl implements ProductService { ProductRepository productRepository; void save(Product product) { // do …

9 architecture  persistence  services 

私はiOSで開発しており、PHPバックエンドからRuby on Railsに切り替えています。交換形式はJSONです。 Googleで「Railsに画像を保存」をすばやく検索すると、画像データをblobとしてデータベースに保存することについてほとんどすべての結果が得られます。誤解しているかもしれませんが、データベースに画像データを保存すると、ファイルの場所（ '/img/subcat/4656.png'へのリンクを保存するのとは対照的に）に多大な時間とスペースが無駄になるという印象を受けます。 PHPでは、データを受け取り、ファイル名を生成し、そのファイルをディスクに保存し、データベースをディスク上のイメージの場所で更新するのはかなり標準的です。これはRuby on Railsでも同じですか、それとも、知らない組み込みのActiveRecord画像機能がありますか？

9 ruby-on-rails  persistence  image 

のclass XFactoryオブジェクトを作成するファクトリがありますclass X。のインスタンスXは非常に大きいため、ファクトリの主な目的は、クライアントコードに対してできるだけ透過的にインスタンスをキャッシュすることです。のオブジェクトclass Xは不変であるため、次のコードは妥当なようです。 # module xfactory.py import x class XFactory: _registry = {} def get_x(self, arg1, arg2, use_cache = True): if use_cache: hash_id = hash((arg1, arg2)) if hash_id in _registry: return _registry[hash_id] obj = x.X(arg1, arg2) _registry[hash_id] = obj return obj # module x.py class X: # ... それは良いパターンですか？（実際のファクトリーパターンではないことはわかっています。）変更すべき点はありますか？ …

9 design  design-patterns  python  caching  persistence 

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

8 java  dependencies  persistence