3つのレイヤーがあるとしましょう
レイヤー 1: WPF プロジェクト (含まれるもの: xaml、viewmodels、mvvm フレームワーク)
レイヤー 2: ビジネス ロジック レイヤー (内容: プレーンな C# クラス)
第 3 層: エンティティ フレームワーク (内容: リポジトリ/データ アクセス クラス)
DAL（レイヤー3）をView（レイヤー1）に公開したくない場合、ビジネスロジックレイヤーをどのように実装しますか? BLL オブジェクトと DAL エンティティの間で値をやり取りするのに苦労しています。
助けていただけますか？
Entity Framework は、「切断された」モデルではうまく機能しません。何かが変わらない限り、簡単にうまく機能させることはできませんでした。
レイヤー 2 で AutoMapper を使用して ViewModel を作成し、レイヤー 1 に提示することもできますが、それでも変更をレイヤー 3 に送り返す必要があり、面倒な作業になる可能性があります。
予見可能な限り変更されない小さなアプリのみを開発している場合は、今最も速い方法を実行してください。長期的に保守可能なアプリが必要な場合は、次のことを提示させてください.
この垂直レイヤー アプローチの問題点は、ビューで何かが必要になるたびに、それをビジネス レイヤー (ビジネス レイヤーが気にしない場合でも) とデータ レイヤーの両方に追加する必要があることです。これには、ビジネス レイヤーが 1) データの UI ビュー、2) データのビジネス ビュー、3) データのデータベース表現のように見える必要があります。それおよび/またはレイヤー間に多くのマッピングが必要です。これらはすべて、ビジネス ロジックを表すというビジネス層の実際の目的を薄めます。その場合、すべてのビジネス ロジックがトランザクション メソッド (静的メソッドでもかまいません) に移行され、データ オブジェクトの状態が変更されるだけです。問題のドメインが複雑なロジックのない CRUD にすぎない場合、それはまったく問題ありません。複雑なロジックで、
複雑なロジックがあると仮定すると、データのユーザー ビューとデータのビジネス表現はしばしば非常に異なるため、UI ビューはデータの特殊なモデルになります。私があなたなら、これを受け入れて、単純なバージョンの CQRS 原則を使用します。つまり、UI ビューのデータは、ビジネス オペレーションが実行される場所とは別の場所から取得します。あなたの場合、DAL に EF モデルがあり、UI ビューのみを提供し、必要なものを正確に提供する可能性があります (データベース ビュー、ストアド プロシージャ、または事前にコンパイルされたレポート テーブルによって)。次に、Business エンティティのニーズのみに対応する別の EF モデルを作成します。次に、実際のビジネス アクションを実行する準備ができたら、UI のビューモデル アクション メソッドは、ビジネス EF モデルからビジネス オブジェクトをロードできます (さらに良いのは、これを行うビジネス層からオブジェクト ファクトリを呼び出して)、ビジネス オブジェクトに対して適切なアクションを実行します。ここでは、データベースが高度なリレーショナル (主に第 2 および第 3 正規形) であり、EF を使用するように設定されていることも前提としています。
ビュー モデルをビジネス ロジックにしようとはしません。これにより、ビジネス ロジックを他のプラットフォームやアプリケーション (Web など) で簡単に再利用できなくなります。MVVM は UI のみを提供する必要があります。私の考えでは、V (ビュー) は、ユーザーが見て操作するものを表します。M (モデル) は、ユーザーがそのビューで選択したものを表します。そして、VM (ビュー モデル) は 2 つの間で変換されます。次に、プログラムは、ユーザーの検証済みの選択 (UI モデル) を取得し、そこから必要なデータを抽出して、適切なビジネス操作を実行する必要があります。
すべての DAL をビュー レイヤーに公開する代わりに、すべてのレイヤー間でドメイン オブジェクト (EF オブジェクト) を交換するだけです。構造は次のようになります。
したがって、すべてのレイヤーが切断されます。ただし、同じドメイン オブジェクトを共有します。現実の世界では、すべてのレイヤーで共有される Entity Framework エンティティ用の個別の dll を作成することにより、同様の構造を実装できます。ObjectContext は DAL にのみ表示されることに注意してください (既定では、エンティティとオブジェクト コンテキストは同じ dll で生成されます。これを 2 つの dll に分ける必要があります)。
あなたViewModels はMVVMのアプリケーションであるため、リポジトリクラスまたはビジネスロジックを介したデータアクセスなどを処理する必要があります（直接または検証クラスを使用して間接的に）。
クラスを直接参照したくない場合は を使用しInterfaceますが、継承したクラスを ViewModel に渡す何らかの方法が必要になることに注意してください。私はかつて、インターフェイスなどの共有インターフェイスのライブラリがあり、すべてが MEF を使用してインポート/エクスポートされたプロジェクトを行ったIRepositoryので、レイヤーは互いに直接参照しませんでした。
最終的な (簡略化された) レイアウトは次のとおりです。
モデル-> 独自のデータ (長さ、最小値/最大値など) に対して単純な検証を実行できるが、高度な検証やビジネス ロジックを実行しない単純なデータ オブジェクトが含まれていました。他のライブラリを参照していません。
共通-> インターフェイス、ユーティリティ、およびその他の一般的に共有されるクラスが含まれています。モデル ライブラリのみを参照しました。
DAL -> 共通ライブラリにあるリポジトリ インターフェイスに基づく、含まれるデータ アクセスとリポジトリ。インターフェイス定義とユーティリティの共通ライブラリ、およびデータ アクセス呼び出しで使用または返されるデータ モデルが含まれていたモデル ライブラリを参照
ViewModels -> 含まれるアプリケーションとビジネス ロジック。ユーティリティとインターフェイスについては Common を参照し、データ モデルについては Models を参照
クライアント-> 含まれるビュー。DataTemplates参照モデルとビューモデル(両方のオブジェクト タイプに書き込み可能)
エンティティフレームワークは、単体で「ロジック層」として利用することを想定しています。
結合技術を使用するというあなたのアイデアには、ある程度の意味があるかもしれません。
しかし、私はそれらのマイクロのいくつかを考えます. 個別に使用するように設計されているライブラリ。
幸運を。