問題タブ [poeaa]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
orm - リポジトリの予想される動作
私は ORM を書いていますが、リポジトリの予想される動作、またはより正確には、リポジトリと作業単位の間のフロンティアが不明です。私の理解では、リポジトリは次のようになります。
Fowler によると ( PoEAA、322 ページ):
リポジトリは、ドメイン レイヤーとデータ マッピング レイヤーの間を仲介し、メモリ内のドメイン オブジェクト コレクションのように機能します。[...] オブジェクトは、オブジェクトの単純なコレクションと同様に、リポジトリに追加および削除できます。
これは、次のテストが機能することを意味します (姓が Fowler である Person が永続化されていると仮定します)。
つまり、データベースへのマッピング時に、どこかで明示的な save() メソッドが呼び出されていなくても、次のクエリで元の Person を含まない正しいコレクションが返されるように、Person モデルがリポジトリによって自動的に永続化されている必要があります。
しかし、どのモデルをいつデータベースに永続化するかを決定するのは、Unit Of Work の役割ではないでしょうか。
上記の実装では、結果が変更と一致するように、リポジトリは別の find() 呼び出しを受け取ったときに以前に取得した Person を永続化することを決定する必要があります。しかし、他の find() 呼び出しが発行されなかった場合、モデルは暗黙的に永続化されませんでした。
Unit Of Work のコンテキストでは、最初にトランザクションを開始し、必要に応じてデータベースへの挿入をロールバックできるため、実際には問題になりません。しかし、このリポジトリを単独で使用すると、予期しない、予測不可能な動作につながることはありませんか?
design-patterns - TableData ゲートウェイと Rowdata Gataway の違いは?.. 明確化が必要
私は最近、TableData Gateway と RowData Gateway について読んでいます。「エンタープライズ アプリケーション アーキテクチャのパターン」によると、RDG は一度に 1 つのレコードを処理し、TDG はテーブル全体を処理します。しかし、これらのパターンはどちらも非常に似ており、SQL クエリをカプセル化します。作成したクエリに基づいて、レコードセット内の単一のレコードまたは多数のレコードを返します.RDG よりも TDG を優先する場合を実際に理解することはできません.いくつかの説明で違いを明確にすることは非常に役立ちます.Martin Fowler によると、TDG は1 つのレコードを返す場合は RDG と同じですが、RDG を複数のレコードに使用することもできます。なぜ TDG を使用するのでしょうか。どんな助けでも大歓迎です。ありがとうございました。
design-patterns - アプリケーションの階層化と DataMapper
こんにちは、「エンタープライズ アプリケーション アーキテクチャのパターン」という本を読みました。彼らは、エンタープライズアプリケーションをレイヤーで実行する必要があり、1つのレイヤーに1つ下のレイヤーのみを使用させることは想定されていないと言います...ドメインレイヤーはDBレイヤーを使用できますが、その逆はできません。次に、ドメイン オブジェクトを作成する DataMappers に関する章があります。DBレイヤーのDataMapperにDomain Layerのオブジェクトを作成させることができるのはなぜですか。それは、下部が上部を呼び出さないという規則に従っていないためです。したがって、私の質問は、実際にはDBレイヤーのドメインオブジェクトであってはならない、またはDBレイヤーにドメインレイヤーを使用させずにドメインオブジェクトを作成する良い方法は何ですか?
asp.net - ASP.NETWebアプリケーションでのDataMappersのストレージ
MartinFowlerの「PatternsofEnterpriseApplication Architecture」では、エンティティのマッパーのセットのようにDALを編成するためのアプローチについて説明しています。それぞれに、特定のエンティティを格納する独自のIdentityMapがあります。
たとえば、私のASP.NETWebアプリケーションでは次のようになります。
}
問題は、これらのマッパーをどこに保存するかということです。システムサービス(エンティティ)はどのようにマッパーを呼び出す必要がありますか?
すべてのマッパーを含むMapperRegistryを作成することにしました。したがって、サービスは次のようなマッパーを呼び出すことができます。
しかし、MapperRegistryインスタンスはどこに保存できますか?次の亜種が表示されますが、どれも好きではありません。
MapperRegistryはアプリケーションに対してグローバルです(シングルトン)
- マルチスレッドASP.NETアプリケーションでの同期が必要なため、適用されません(少なくとも、Martinは、このバリアントを選択できるのは狂牛病だけだと言っています)
セッションごとのMapperRegistry
- あまり良くないようです。すべてのORM(NHibernate、LINQ to SQL、EntityFramework)マスターは、リクエストごとにDataContext(NHibernateSession、ObjectContext)を使用し、Sessionにコンテキストを格納しないようにアドバイスします。
- また、私のWebAppでは、ほとんどすべてのリクエストは、JSONを返すEntityController.asmx(属性ScriptServiceを使用)へのAJAXリクエストです。そして、セッションは許可されていません。
リクエストごとのMapperRegistry
- 個別のAJAX呼び出しがたくさんあります。この場合、MapperRegistryのライフサイクルは小さすぎます。そのため、ほとんどの場合、データはデータベースから取得され、その結果、パフォーマンスが低下します。
親愛なる専門家、建築ソリューションを手伝ってください。
php - Zendでは、なぜDB ModelクラスとMapperクラスを2つの別々に使用するのですか?
私はzendプロジェクトに取り組んでおり、他のzendプロジェクトを参照して、新しいZendプロジェクトを作成していますが、理解せずにそのプロジェクトを盲目的にフォローするのは好きではありません。Zend Directory構造では、Modelクラスには、主に2つのタイプのクラスがあります。
なぜこの特定の構造に従うのですか?これは、オブジェクトクラスとデータベースモデルクラスを分離するためですか?
説明してください。
php - データマッパーはどのようにドメインオブジェクトを返す必要がありますか?
モデルレイヤーには、データマッパー、ドメインオブジェクト、および「サービス」(モデルレイヤーの外部に接続するため)があります。DomainObjectFactoryとDataMapperFactoryを実装することを選択したため、DM<->DOの関係に固執しました。理想的には、データマッパーは「get」/「read」を実行するすべてのメソッドに対して関連するドメインオブジェクトのインスタンス(またはインスタンスの配列)を返しますが、データマッパーはドメインオブジェクトファクトリにアクセスできません。
DMとDOのファクトリパターンがないと、オートローダーがDM内を引き継いで、DOのインスタンスを作成できます。しかし、これは工場でどのように達成されますか?
私が考えることができる1つの可能な解決策は、関連するドメインオブジェクトのインスタンスをデータマッパーメソッドに渡すことです。
このオプションは非常に汚いようですが、単一のgetメソッドでは機能します。ただし、ドメインオブジェクトの配列を返す場合は意味的にオフザレールになるため、これを実現するための最善の方法ではないことは明らかです...別のオプションは、データマッパーがドメインオブジェクトファクトリにアクセスできるようにすることです。しかし、それは大規模なLOD/SRP違反になります。
つまり 、データマッパーがドメインオブジェクトファクトリにアクセスして、ドメインオブジェクトを返すことができるようにするにはどうすればよいでしょうか。
sql-server - 複数の浮動小数点列を BLOB に置き換える必要がありますか?
SQL Server の 1 つの BLOB 列は (パフォーマンスに関して)、~20 個の REAL 列 (20 x 32 ビット浮動小数点数) とどのように比較されますか?
Martin Fowler が (エンタープライズ アプリケーション アーキテクチャのパターンで) 大きなオブジェクト グラフを永続化するために BLOB を使用して、クエリで複数の結合を削除することを推奨したことを覚えていますが、20 個の固定列を持つテーブルに対してこのようなことを行うことは理にかなっていますか?クエリ)?
このテーブルは非常に頻繁に (毎秒約 100 回) 更新INSERTされ、クエリで指定されたすべての列でステートメントがかなり大きくなります。
最初の答えは「自分でプロファイリングする」になると思いますが、誰かがこのような経験をすでに持っているかどうか知りたいです.
design-patterns - 行データ ゲートウェイの戻り値
最近、poeaa で行データ ゲートウェイ パターンについて読みました。
私の質問は、行データ ゲートウェイ パターンによる戻り値は何ですか。ゲートウェイ オブジェクト自体ですか。もしそうなら、これは DAL と BLL の間の依存関係を追加しませんか?
つまり、リポジトリ パターンのように、DAL -> BLL という関係があります。たとえば、次のようになります。
ただし、ゲートウェイでは、関係は次のようになります: BLL -> DAL、たとえば:
私は何かを誤解していますか?
design-patterns - クエリ オブジェクトと仕様パターンの違い
Martin Fowler が提案した Query Object パターンと Eric Evans が提案した Specification パターンの違いは何ですか?