5

StackOverflow や他のサイトで、アーキテクチャのベスト プラクティスに関する記事を 1 日中読んでいますが、相反するアイデアや意見が非常に多くあります。

最終的にアプローチに落ち着きましたが、EF オブジェクト (DbContext、Fluent API、シード データなど) を配置する場所を決定するのに非常に苦労しています。これが私が現在持っているものです：

ASP.NET MVC プロジェクト: 実際の Web プロジェクト。標準のビュー、コントローラー、およびビュー モデルが含まれています ( Modelsフォルダー内)。

Domain Model Project : データベース (ドメイン) オブジェクトを定義するすべての POCO クラスが含まれています。現在、EF オブジェクトについて言及または参照していません。

Service Layer Project : 各タイプのドメイン オブジェクト (IProductService、IOrderService など) のサービス オブジェクトが含まれます。各サービスは、DbSets などの EF オブジェクトを参照し、ビジネス ルールを処理します。たとえば、製品の追加、製品の取得、注文への製品の追加などです。

問題は、この構成では、EF クラスはどこに行くのかということです。最初はサービスレイヤーで考えましたが、それは意味がないようです。次に、それらをドメイン モデル レイヤーに配置することを考えましたが、ドメイン モデルを EF (本質的には DAL/リポジトリ) に結び付けます。最後に、EF 専用の別の DAL プロジェクトを作成することを考えましたが、3 ～ 4 個のファイル (DbContext と他のいくつかの小さなファイル) が含まれる可能性が高いことを考えると、非常に無駄に思えます。

誰でもガイダンスを提供できますか？

4

2 に答える 2

3

冗長性があるため、ドメイン モデルは必要ありません。EF クラスは直接ドメイン モデルとして機能し、ビューに送信するときにビュー モデルに変換されます。EF は別のクラス ライブラリに分離できます。それらのほとんどは、交換が容易な場合に備えて、ORM と一緒にリポジトリ パターンを使用します。しかし、リポジトリ パターンの使用に対する批判を見てきました。これを確認してください。

于 2013-06-01T05:34:32.653 に答える
3

これが私がすることです：

データ：

  • DbContext から継承する 1 つのクラスがあります。
    • すべてのデータベースセットがあります。
    • OnModelCreating をオーバーライドします。
    • 主キーと関係のマッピング。

エンティティ:

  • すべての POCO クラスがあります。
    • 各プロパティは、必要なデータ注釈で装飾されています。

サービス:

  • 各サービスには共通のメソッド (GetList()、Find()、Create() など) があります。

仕事：

  • クライアントから呼び出され、特定のタスクを実行するためにサービスを使用して調整します UserChangePassword (これは、これが実行できるかどうかを確認してから、タスクを実行するか、クライアントにタスクに関する正しい情報を表示させるために、他の多くの中でエラー/未承認のステータスを返します。これは、私の場合、私がログインする場所です。

クライアント (デスクトップ/Web/Wpf/など)。

これが最善のアプローチだと言っているのではありません。

于 2013-06-01T06:12:55.390 に答える