問題タブ [persistence-ignorance]

詳細については触れませんが、いくつかのクライアント アプリケーションで使用されるサービス ベースのソリューションを設計しようとしています。このソリューションにより、管理者は、通常のユーザーがデータ入力を実行するために使用するドキュメント テンプレートを作成および変更できます。アプリケーションをベスト プラクティスやテクニックなどの学習ツールにすることが私の意図です。

同時に、私は統合失調症の環境に適応しなければなりません。なぜなら、「権力者」はテクノロジーやツールに関する決定に固執することができないからです。たとえば、私は今日、Linq-to-SQL を使用しています。なぜなら、それらは EF4 に移行する準備ができていないためですが、NHibernate への切り替えについての議論もあります。したがって、OR/M ツールを変更した場合に必要な作業を最小限に抑えるために、コードを可能な限り永続的に無視する必要があります。

この時点では、部分クラス アプローチを使用して Linq-to-SQL クラスを拡張し、ビジネス レイヤーで定義されたインターフェイスを実装することにも制限されています。経営陣はすべての組み込みツールなどを活用することを主張しているため、POCO を使用することはできません。そのため、Linq-to-SQL デザイナーをサポートする必要があります。

とはいえ、私のサービス インターフェイスには、シグネチャでテンプレート識別子を受け入れる StartSession メソッドがあります。操作の流れは次のとおりです。

1. 現在のユーザーと指定されたテンプレートのセッションがデータベースに既に存在する場合は、レコードを更新して現在のアクティビティを表示します。そうでない場合は、新しいセッション オブジェクトを作成します。
    
2. セッションはテンプレートのインスタンスに関連付けられており、それを「フォーム」と呼びます。したがって、セッションが新しい場合は、テンプレート情報を取得して新しい「フォーム」を作成し、それをセッションに関連付けてから、セッションをデータベースに保存する必要があります。一方、セッションが既に存在する場合は、ユーザーが入力し、以前にセッションに保存したデータを含む「フォーム」もロードする必要があります。
    
3. 最後に、セッション (フォーム定義とデータを含む) が呼び出し元に返されます。
    

私の最初の目的は、アプリケーションの論理レイヤーを明確に分離することです。2 つ目は、持続性の無視を維持することです (前述のとおり)。第三に、すべてをテストできる必要があるため、簡単にモックできるようにすべての依存関係を外部化する必要があります。この分野で役立つ IoC ツールとして Unity を使用しています。

これを実現するために、サービス インターフェイスをサポートするために、必要に応じてサービス クラスとデータ コントラクトを定義しました。サービス クラスには、実際に作業を実行するビジネス層から注入された依存関係があります。そして、ここが私にとって厄介になったところです。

私は、永続性の無知を助けるために、作業単位とリポジトリのルートに行こうとしました。IUnitOfWork 実装からアクセスできる ITemplateRepository と ISessionRepository があります。サービス クラスは、SessionManager クラス (BLL 内) のインスタンスを挿入します。SessionManager は、コンストラクター インジェクションによって IUnitOfWork の実装を受け取り、すべての永続性を UoW に委任しますが、さまざまなロジックでシェル ゲームをプレイしていることに気づきました。

上記のすべてのロジックは、SessionManager クラスまたは UoW 実装に含まれている必要がありますか? データ アクセス プラットフォームを変更すると、アプリケーション ロジックに不要な変更が加えられる可能性があるため、リポジトリ実装のロジックはできるだけ少なくしたいと考えています。私のリポジトリはインターフェイスに対して機能しているため、新しいセッションを作成するにはどうすればよいですか (有効なセッションには、使用されているテンプレートへの参照があることに注意してください)。デザイナーをサポートし、リポジトリ実装内で AutoMapper のようなツールを使用してオブジェクトの翻訳を処理する必要がありますが、POCO を引き続き使用する方がよいでしょうか?

うーん！

私は分析麻痺で立ち往生していることを知っているので、おそらく少しのナッジが必要なのです. 理想的なのは、私が定義したビジネス ルールとアーキテクチャ上の制約が与えられた場合に、問題をどのように解決するかの例を誰かが提供できる場合です。

既存の製品のポイント リリースである今後のプロジェクトで Microsoft の Entity Framework を使用することを検討しています。現在の製品は 2 つの DBMS (Oracle と SQL Server) をサポートしており、それぞれのスキーマは個別の .sql スクリプト ファイルに保持されています。

エンティティ フレームワーク (4.1) は、コード生成、リフレクションなどを介してさまざまなシナリオを自動的に実装できるため、魅力的に見えます。しかし、私が知る限り、これらの利点のいくつかは相互に排他的であるように見えます。

たとえば、複数の DMBS をサポートするには、モデルまたはコードを最初に設計する必要があると推測しています。その場合、EF はモデルに従ってそれぞれのスキーマを生成します (これに関する投稿やドキュメントはほとんどまたはまったく見たことがありません)。ので、間違っているかもしれません）。これは、既存のスキーマを放棄する (モデル優先) か、マップする (コード優先) 必要があることを意味します。さらに、EF はスキーマのアップグレードを (データを消去せずに) サポートしていないように見えるため、スキーマの更新には手動のスクリプトが必要になります。

1. モデル ファーストとコード ファーストは、EF で複数の DBMS をサポートする唯一の実行可能な手段ですか? 任意の 2 つのスキーマが同じであることを保証することは技術的に不可能であることを認識しているため、これは正しいと考えています。
2. コード ファーストと複数の DBMS システムへのマッピングの潜在的な落とし穴はありますか? たとえば、Oracle には自動インクリメント列がありません。シーケンスを使用する必要があります。これは DbContext でどのようにマップされますか? DBMS ごとに個別のマップを作成する必要がありますか?
3. EF は、既存の DBMS スキーマを EF モデルを代表するものにアップグレードするメカニズムをサポートしていますか (スキーマの再作成 =/= アップグレード)、またはこれを手動で行うことに制限されていますか?
4. 最初にデータベースを使用して複数の DBMS をサポートする方法を 1 つ思いつきましたが、これはメンテナンスの悪夢です。アイデアは、生成された 2 つのデータ モデルに抽象化の別のレイヤーを追加し、EF で生成されたモデルごとにコンバーター クラスを作成することでした。これは、各 DBMS が潜在的に独自のモデルを持つことができるようにするための最良の方法のように思えますが、私のコードはマッピングを処理します。しかし、これを行うことで、EF から実際に得られるものは何でしょうか? おそらくクエリ生成ですが、それだけの価値はありますか?

私は、持続性の無知を尊重しようと積極的に取り組んでいる新しいプロジェクトに取り組んでいます。例として、私のサービス レイヤーでは、ORM からエンティティを取得し、エンティティに変更を加える場合としない場合があるエンティティで定義されたルーチンを呼び出します。次に、ORM に依存して、エンティティが変更されたかどうかを検出し、必要な挿入/更新/削除を行います。

アプリケーションを実行すると、意図したとおりに動作し、これが実際に動作しているのを見るのは本当に素晴らしいことです。私のビジネス ロジックは非常に分離されており、私のサービス レイヤーは非常に薄いです。

もちろん、今は単体テストを追加していますが、特定のプロパティが変更されたかどうかを検証する単体テストを記述できないことに気付きました。以前のソリューションでは、オブジェクトが期待される状態でリポジトリ呼び出しが行われたかどうかを判断しました。

持続性の無知に正しく近づいていますか? リポジトリの保存メソッドを明示的に呼び出さない場合に、エンティティの操作後の状態を単体テストするより良い方法はありますか?

それが役立つ場合、私は ASP.NET MVC 3、WCF、NHibernate、および NUnit/Moq を使用しています。単体テストは、サービス クラスのインスタンスを渡すコントローラー アクションを呼び出します (モック リポジトリでインスタンス化されます)。

私は現在、定義済みの標準構造で任意のデータベースからデータを抽出するための WCF データ サービスを作成しています。

POCOエンティティを使用することを考えていました。EF デザイナーでエンティティを設計し、そこから POCO クラスを生成できますが、データ アクセス レイヤーを記述して DBContext に挿入する方法を理解するのに少し苦労しています。

したがって、異なるデータベースごとに、データベースまたは xml ファイルからデータを取得し、そのデータを POCO エンティティにマップするデータ アクセス レイヤーを用意します。

これがまったく達成可能かどうかはわかりません。

POCO クラスは、世界に公開する私の標準的な構造になります。カスタム SQL クエリを記述して DB からデータを抽出し、そのデータを POCO クラスに設定する場所がどこにもありません。POCO クラスはどのデータベース テーブルとも一致しないため、データベース フィールドを POCO クラスに明示的にマップする必要がありますが、POCO を使用して Entity Framework でこれを行う方法がわかりません。

POCOは書き込みオプションだと思いますが、データアクセスレイヤーとデータベースからPOCOクラスへのマッピングに苦労しています。

私が見たすべてのサンプルは、EF を既存のデータベースに直接接続することについて話しています。つまり、EF 構造はデータベースの構造と一致する必要があります。私が欲しいのは、複数のデータベースからデータを取得できる単一の EF/POCO 構造です。これらのデータベースは同じ構造ではありませんが、これらのデータベースから手動でデータを取得し、POCO クラス構造に変換する必要があります。必ずしも複数のデータベースから一度にデータを取得したいわけではなく、単一の DB からデータを取得したいのですが、どのデータベースにも同じモデルを使用したいので、DB からデータを取得するデータベースごとにカスタム DAL を作成する必要があると思います。データを POCO モデル構造に変換します。

誰かが私を助けてくれれば本当に感謝しています。

ところで、私は EF を初めて使用するので、しばらくお待ちください。

SQL Server データベースがあり、LINQ to Entities を使用して WCF レイヤーでラップし、クライアントに公開したいと考えています。(典型的な N 層アーキテクチャ)。また、Persistence ignorant オプションが必要であり、データベース内の特定のフィールド (機密情報) を無視してクライアントにシリアル化するオプションも必要です。

したがって、Entity Framework を Persistence Ignorance で使用し、WCF をサポートして Self Tracking を使用するための最良のアプローチは何でしょうか。Self Tracking または Persistence Ignorant のいずれかを含む T4 テンプレートを見つけることができました..しかし、すべてが単一のパッケージとしてバンドルされています。

これについての助けをいただければ幸いです。

報告戦略についてアドバイスが必要です。現在CrystalReportsを使用していますが、ここでは関係ないかもしれません...テクノロジーの選択が問題である場合は、別の何かを使用できます。

私はかなり複雑な請求を処理するアプリケーションを構築していますが、結局のところ、それらはすべてGetTotalsです。永続性の無知は順調に進んでいます。私は単独でテストしており、後ですべてを保存できます。

しかし、請求書の合計について報告したいとします。これらの合計の生成は、データベースではなく、アプリケーションの一部です。そのロジックをデータベースに複製したくありません。以前は、最初から請求ロジックをデータベースに組み込んでいましたが、それにより、アプリケーションに関してはかなり脆弱な戦略に陥ることになります。

この競合を解決するにはどうすればよいですか？

アドバイスありがとう、

-イーサンネルソン

エンティティを永続性とサービスに依存しないようにしようとしていますが、エンティティのBLOBおよびファイルに対応するプロパティに関しては問題が発生しています。集合体の中に、そのようなエンティティがあるとしましょう（たとえば、基本的なものに保たれています）。

私が検討した、または検討しているアプローチ：

1. のようなメソッドを使用して、サービスインターフェイス、「FileProvider」などを作成しますload (Attachment $file)。その実装者は、ファイルのバイナリを取得して返す方法を知っています。
   • これにより、データアクセスロジック（FileProviderMysql、FileProviderDirectory、FileProviderRemoteFTPなど）の複数の実装が可能になります。
   • これは、エンティティまたは値オブジェクト内に収まらないように見える動作をカプセル化するオブジェクトとしてのサービスクラスのEricEvansの説明に適合しているようです。
   • Evansの本には、サービスクラスが、単純化された意図を明らかにするインターフェイスを使用して、厄介なインターフェイスまたはレガシーインターフェイスへのアクセスをカプセル化する例もあります。
2. おそらく、エンティティ自体に上記のインターフェイスの実装を注入して、エンティティのコンテンツを他のプロパティと同じ構文でオンザフライで取得できるようにします。
   • このように、アグリゲートのリポジトリ（またはその現在の戦略）は、現在のストレージ実装に対応するサービス実装を注入する機能を持ち、クライアントとアプリケーションサービスがその呼び出しを行うことから解放されます
   • ただし、エンティティがサービスインターフェイスについて本当に「知っている」必要があるかどうかはわかりません。

このシナリオの経験がある人は、私が決断を下すのを手伝ってくれませんか？私がしている仕事が持ちこたえることを確認したいと思います。ありがとうございました...