問題タブ [service-layer]

ユーザー登録用の RegisterModel と、IUserService を実装する UserService があるとします。

RegisterModel が非常に複雑な場合、RegisterModel を User オブジェクトにマッピングするためのロジックはどこにあるのでしょうか。

EntityFramework4を使用してASP.NETMVC3アプリケーションを作成しています。リポジトリ/サービスパターンを使用しており、フィードバックを探していました。

私は現在次のものを持っています：

MVCアプリケーション（GTG.dll）

• GTG
• GTG.Controllers
• GTG.ViewModels

ビジネスPOCO（GTG.Business.dll）

• これには、すべてのビジネスオブジェクト（顧客、注文、請求書など）が含まれます。

EFモデル/リポジトリ（GTG.Data.dll）

• GTG.Business（GTG.Context.tt）エンティティPOCOジェネレーターテンプレートを使用しました。
• GTG.Data.Repositories

サービスレイヤー（GTG.Data.Services.dll）

• GTG.Data.Services-集約ルートごとに1つずつ、すべてのサービスオブジェクトが含まれます。

以下は、小さなサンプルコードです。

コントローラ

モデル

サービス

リポジトリ

サービスレイヤーによって呼び出されるデータアクセスを担当するリポジトリレイヤーがあります。サービス層は、シリアル化されてネットワーク経由で送信される DTO を返します。多くの場合、サービスはリポジトリにアクセスし、リポジトリが返すものを返すだけです。

しかし、それが機能するには、リポジトリがその DTO のインスタンスを返す必要があります。それ以外の場合は、最初に、リポジトリが返すデータ レイヤー オブジェクトをサービス レイヤーの DTO にマップし、それを返す必要があります。それは無駄に思えます。

その上、DTO の作成がサービス レイヤーで発生する場合、以前は 1 つのリポジトリ呼び出しで 1 つのデータベース クエリで実行されていた可能性があることを、サービス レイヤーで複数のリポジトリ呼び出しで実行して「作成」する必要があります。最終DTO。もちろん、そのような合成オブジェクトを含むことができるデータ層とサービス層の間のトランスポート オブジェクトを作成しない限り。次に、 DTOにマップする必要があります。純粋さのために無駄に思えるだけです。しかし、ネットワーク経由で送信するために存在するだけのオブジェクトをリポジトリ層に返すのも、間違っているように感じます。

サービス層に検証コードを配置するように言っている本や記事の例をたくさん見てきました。ドメイン オブジェクトを「ダム」(別名、純粋な POCO) に保ち、ドメイン オブジェクトがサービス層で行う可能性のあるすべての検証を処理します。

サービス層は、見かけ上（または少なくともそうである可能性があります）、非常に多くの責任を負っています。ユーザー認証、ロール認証、IoC の依存関係オブジェクトのスクリプト作成 (ロガー、エラー ハンドラーなど)、ドメイン オブジェクトのスクリプト作成、リポジトリのスクリプト作成、およびリポジトリとの間でのドメイン オブジェクトの受け渡し...

サービス層でこれらすべてのルールを作成することは、ドメイン オブジェクトに重大な脅威をもたらしませんか? たとえば、一部のプログラマーがドメイン オブジェクトに対して直接消費するコードを記述し、サービス層を完全にバイパスすることを決定した場合はどうなるでしょうか? それは悪いことですが、信じられる状況です。

すべてのドメイン オブジェクトの検証を含め、サービス層に多くの責任を負わせようとしている場合、誰かがそれらを直接スクリプト化しようとしたときに、ドメイン オブジェクトを「保護」する方法はありますか? たとえば、何らかの方法でドメイン オブジェクトが特定のクライアント (この場合はサービス層?) によって使用されていない可能性があります。

優れた設計とは、ドメイン オブジェクトが、誰が呼び出しているのか、どのように呼び出されているのかについて何も知らなくてもよいと私に思わせるものです。

ドメイン オブジェクトを「ロックダウン」する方法がない場合、ドメイン オブジェクトの検証をサービス レイヤーに配置することを提案する記事や書籍が非常に多いのはなぜですか? 防御的なプログラミングの立場を取ることで、ドメイン オブジェクトを防弾となるように構築し、UI と BAL/DAL の間で要求を転送および受信するための単純なコード レイヤーとしてサービス レイヤーに依存する必要があると想像できます。

サービス層を迂回した人々によるドメイン オブジェクトの「悪用」について、実際のプロジェクトで経験した人はいますか?

私は新しいASP.NETMVCアプリケーションに取り組んでおり、EF4クラスとPOCOクラスを使用してサービスレイヤー/リポジトリ/UOWパターンを実装するために最善を尽くしています。

私がこれを正しく理解しているかどうかを確認するのを手伝ってください。

これを単純にするために、クライアントが顧客のビューを要求しているとしましょう。

1）クライアントがCustomerControllerにビューを要求します。
2）CustomerControllerは、新しいUOWとUOWを渡す新しいCustomerServiceを作成します。 3）CustomerServiceは（Customerの）新しいリポジトリを作成し、 CustomerServiceから受け取ったUOWを渡します。これは、「この顧客を表示できますか？」のように言うレイヤーです。 4）CustomerRepositoryは、 EF4からのPOCOクラスの取得を処理します。 5）CustomerRepository


POCOクラスをCustomerServiceに戻し、CustomerServiceはそれらをCustomerControllerに戻します。 6）CustomerControllerは、POCOクラスを使用してCustomerViewModelを埋めてから、CustomerViewModelをCustomerViewに渡します。

AutoMapperを使用する理由/場所についてはまだ少し混乱していますか？

これに関するアドバイスをいただければ幸いです。

私はこのデザイン コンセプト全体に不慣れで、ここ数週間の読書で多くの情報を集めましたが、散らばっていて矛盾しているように見えます。条件はまちまちで、私はこれを理解するのに苦労しています。

私が使用しているパターンは次のようなもので、次のような流れを想定しています。

MVC アプリケーション
コントローラーは、特定のビューに対するクライアントからの要求/応答を処理します。コントローラーのアクション メソッド内で、サービス (サービス レイヤー) に接続し、オブジェクトを要求してビュー モデルを構築し、ビュー モデルからオブジェクトを送り返します。

ビュー モデル ビュー
との間で強く型付けされたビュー モデルを使用しています。

ビュー モデルは DTO ですか? Name、AddressLine1、Address City などの単純なプロパティだけを含めるか、複雑なプロパティや複数のオブジェクトなどを含める必要があります。

ビューモデルでの検証です。もしそうなら、それは必須フィールド、フィールド長などの検証になりますか?ユーザー名などの検証は既に存在しますか、それともサービス層の他のオブジェクトと対話する必要がある場所ですか?

ビュー モデルに EF から返された POCO クラスのみを含めることはできますか?それとも AutoMapper を使用する必要がありますか?

AutoMapper と DTO を使用している場合、DTO のクローンは POCO クラスですか?

コントローラー、ビュー モデル、または下のサービス レイヤーにマップしますか?

サービス
私にとって、サービスとは、EF から POCO オブジェクトを取得するためにリポジトリに接続するオブジェクトです。これは、すべてのビジネス ロジックが存在する場所です。サービスがオブジェクトをリポジトリに戻して EF に永続化すると、それらは有効なオブジェクトと見なされます。これは正しいです？

リポジトリ
それらにはビジネス ロジックはありません。サービスと EF の間でオブジェクトを転送するためにのみ使用されます。これは正しいです？ここでは、汎用リポジトリを使用してインターフェイスを実装しています。次に、特別なニーズに合わせて汎用リポジトリを拡張できますか?

用語に関する質問
1) ビジネス オブジェクトはドメイン オブジェクトと同じですか。ドメイン オブジェクトにはどのくらいのロジックを含める必要がありますか?

2) ドメイン モデルは EF モデルですか? モデルファーストのアプローチを使用しています。

3) 依存性注入 - これを使用する必要がありますか? 私はそれがどのように機能するかを理解していますが、本当の利益を得られません. 私はNinjectで遊んでいました。

コミュニティは、コード サンプルを含むすべてのベスト プラクティスを含むある種の wiki から恩恵を受けると思います。そこにそのようなものはありますか？出回っているサンプルの多くは非常に単純であり、Microsoft のサンプルの多くは、主張して​​いる場合でもこのパターンを使用していません。

これを手伝ってくれるすべての人に前もって感謝します。

ところで-StackOverflowには、「Accept Answer」チェックボックスの横にある「Buy Me A Beer」ボタンが少し必要だと思います:)

EF4でサービスレイヤー/リポジトリ/作業単位パターンを使用してMVCアプリを構築しています。

私は論理について少し混乱しています。システムを切り離すことがポイントであることは知っていますが、少し混乱しています。

そのため、MVCコントローラーはサービスを呼び出してビューモデルを埋めます。では、MVCアプリがサービスレイヤーに結合されていると言っても安全ですか？

次に、サービスレイヤーはリポジトリを呼び出して、オブジェクトを取得して永続化します。それなら、サービスレイヤーはリポジトリに依存していると言っても安全ですか？

リポジトリはEF4を利用してデータを取得してSQLServerに永続化するため、リポジトリはEF4に依存し、EF4はSQLServerに依存していると思います。

作業単位はどこに収まりますか。

例はありますか？ありがとう！！

MVC アプリで UnitOfWork/Service Layer/Repository/EF4 w/POCO 設計を使用しています。

これまでのところ、私はこれを持っています:

1) MVC Web アプリ (Project.dll)
2) サービス層 (Project.Data.Services.dll)
3) リポジトリ層 (Project.Data.Repositories.dll)
4) POCOS (Project.Data.Domain.dll)
5) EF4/コンテキスト レイヤー (Project.Data.dll)

各レイヤーは、その下のレイヤーと Project.Data.Domain (POCO クラス) のみを参照します。

現在、Project.Data.dll に UnitOfWork Interface/Base がありますが、すべてのレイヤーがそれを参照する必要があります。それは設計が悪いのでしょうか？もしそうなら、それはどこに住んでいますか？

私はまだこれに頭を悩ませています。次のようにレイヤー（dll）を分離したい：

1) MyProject.Web.dll - MVC Web アプリ (コントローラー、モデル (編集/表示)、ビュー)
2) MyProject.Services.dll - サービス層 (ビジネス ロジック)
3) MyProject.Repositories.dll - リポジトリ
4) MyProject。 Domain.dll - POCO クラス
5) MyProject.Data.dll - EF4

ワークフロー:

1) コントローラーはサービスを呼び出して、オブジェクトを取得し、モデルの表示/編集を行います。
2) サービスはリポジトリを呼び出して、オブジェクトを取得/保持します。
3) リポジトリは EF を呼び出して、SQL Server との間でオブジェクトを取得/永続化します。

私のリポジトリは IQueryable(Of T) を返し、その中で ObjectSet(Of T) を利用します。

これを見ると、レイヤーは正確に次のレイヤーとPOCOクラスを含むライブラリに依存していますか?

いくつかの懸念事項:

1) リポジトリが EF で正しく動作するためには、それらは System.Data.Objects に依存します。これで、リポジトリ レイヤーで EF と密結合になりました。それは悪いことですか?

2) UnitOfWork パターンを使用しています。それはどこに住むべきですか？これには ObjectContext としての Property Context があるため、EF にも密接に結合されています。悪い？

3) これを簡単にするために DI を使用するにはどうすればよいですか?

テストのために、これを可能な限り疎結合にしたいと考えています。助言がありますか？

- - - - - 編集 - - - - -

ここで正しい軌道に乗っているかどうか教えてください。また、サービスには IRepository(Of Category) の権利が注入されますが、それと EFRepository(Of T) の具象クラスとの違いをどのように認識しますか? UnitOfWork と Service と同じですか?

誰かが私が理解できるところまでこれを理解するのを手伝ってくれたら、それは些細なことのように思えるでしょうが、私はこれに頭を悩ませています!!

コントローラ

サービス

リポジトリと UnitOfWork

MVC アプリで Service/Repository/EF/POCO パターンを使用していますが、インターフェイスについていくつか質問がありました。

1) サービスごとにインターフェイスを作成する必要がありますか? 2) リポジトリごとにインターフェイスを作成する必要がありますか?

または、レイヤーごとに汎用インターフェイス (IService(Of T)、IRepository(Of T)) を用意する必要があります。

私が理解していないのは、コントローラーで言うと、コンストラクターで IService(Of Category) インターフェイスを使用する方法です。具象クラスにメソッドを実装するにはどうすればよいですか?

_Service には、具体的な CategoryService クラスのメソッドがありませんか?

意味がありますか？