問題タブ [service-layer]

多数のレイヤーを持つ大規模な Web アプリを構築しています。ビジネス層と通信するために、データが必要なときに Web 層が呼び出すサービス層を使用しています。残念ながら、ビジネス層で例外がスローされた場合、Web 側のサービスが例外をラップして再スローしているようです。WCF が元の例外を新しい例外でラップすることなく、エラーをカプセル化してログに記録する明確な方法を探しています。

ありがとう

つまり、リポジトリにメソッドがあるとしましょう。

サービスがこの拡張機能の形式で追加データを取得して、顧客の注文を取得できるようにする必要があります。

この拡張機能は、一般的なリポジトリで使用される可能性があります。

または、サービスに必要なものを正確に返し、多かれ少なかれ何も返さない、集約ルートごとのリポジトリの具体的な実装が必要ですか？

次に、リポジトリはIQueryableを返す必要がありますか？

先日、こんな質問をしました。

リポジトリ層はデータ転送オブジェクト (DTO) を返す必要がありますか?

答えは (たった 1 人によるものですが、それは良い考えではないという予感が既にありました)、いいえ、リポジトリは後で DTO オブジェクトを処理する必要はないというものでした (それらの目的は純粋にサーバー経由で送信されることです)。ワイヤー) であり、サービス層がそれを処理する必要があります。

今、私はその間にあなたの意見が必要な構造を思いついた. その考えは、そうするのが理にかなっている場合、リポジトリ層は、私が定義した と呼ばれるインターフェースタイプを返すことができるということIProjectableです。これはクエリをラップします（リポジトリレイヤーはまだクエリを実行しません）が、消費者がクエリを変更することはできません（それはそうではありません）IQueryable。実際にクエリを実行します。FirstToPagedList

したがって、リポジトリでは次のようになります。

そして、サービス層では次のようになります:

ここで実際のデータアクセスを行うことは、依然としてリポジトリレイヤーの責任であり(そうあるべきです)、シリアライズ可能なフォームへの射影はサービスレイヤーの責任である(そうあるべきである)というのは正しいですか?

これを効率的に行うための他の唯一の方法(Userリポジトリからa を返しCount()、Ordersサービス層でこれを実行すると、データベースへの余分なクエリが発生します) は、これらすべてのプロパティを持つ型を定義し、これは、「純粋さ」のために同じ名前を付けていないだけで DTO と同じであるため、ばかげているように思えます。このようにして、私は自分のケーキを持って、ほとんどの場合それを食べることができるようです.

私が見る欠点は、サービスレイヤーが実際にSQLに変換できないプロジェクションを実行する場所で不一致が発生する可能性があることです。これは心配する必要はありません.実際のデータアクセスを行います。

ところで、私は Entity Framework 4 を使用しています。

私はエンタープライズ向けのMicrosoft.Netソリューションの設計を読んでおり、プレゼンターとサービスレイヤーに関していくつかのことを理解しようとしています。

まず、Presenterは、initialize（）、save（）など、サービスレイヤーに存在するメソッドを呼び出す必要があります。しかし、サービスレイヤーへの参照はどこに配置しますか？プレゼンターでクラスレベルにする必要がありますか、それともプレゼンターメソッド自体で新しいサービスを定義する必要がありますか？

第二に、これは本でもあまり明確ではありませんが、これはプレゼンターからサービスレイヤーへの処理がどのように機能するのですか？：

皆さん、こんにちは。

MVC サービス層の設計に関する多くの議論を調査して見つけましたが、正確な質問に対する答えは見つかりませんでした。サービス層の相互依存性に関する投稿には、私が考えていることを説明する画像がありますが、参照された投稿でカバーされているとは思えない追加の質問があります。

私のアプリケーションは、複数のコンテキストで人間とやり取りする非営利団体のデータを追跡します。その人間はクライアントだったのかもしれないし、アドバイザーだったのかもしれないし、敵だったのかもしれない。それらは複数にすることができます。クライアントは後で敵対者になる可能性があります (弁護士のクライアントを考えてみてください)。

私の考えでは、新しいクライアントまたは新しい敵対者を作成すると、常に 2 つのレコードが作成されます。1 つのレコードは person テーブルに、1 つのレコードは ancillary テーブルに作成されます。この背後にある私の考えは、ビジネスが特定の人物と過去にやり取りがあったかどうかを確認する場所 (人物テーブル) が 1 つあるということです。

私の質問は、エンティティをコントローラ レイヤと 1 対 0..1 の関係で表す場合、(1) クラスをビューに渡す前にクラスの結合と分割にコントローラを関与させる必要があるかどうかです。(2) そうでない場合、サービス層はビューモデルを構築する必要がありますか?

ここで1800 ライン コントローラに関する投稿を読みました。また、サービス レイヤーはビュー モデルについて認識すべきではないというこの投稿も読みました。これは、コントローラー レイヤーで生きて死ぬと考えさせられます。たとえば、サービス レイヤーがビューモデルに触れていない場合、 (3)とオブジェクトの両方をコントローラーに返すのは適切な設計ですか?workerServicePersonWorker

ここに私のエンティティクラスがあります:

私はこのService Layer --> Repository --> Entity Framework (Code-First) w/POCO objectsアプローチを使用していますが、エンティティの更新に苦労しています。

AutoMapper を使用してドメイン オブジェクトをビュー モデルにマップしていますが、データを取得するのに適していますが、その変更をデータベースに戻すにはどうすればよいですか?

純粋な POCO オブジェクトを使用すると、変更追跡のようなものはないと想定されるため、自分で処理するしか選択肢がないことがわかります。ビュー モデルがドメイン オブジェクトとまったく同じプロパティを持っていることを確認しますか? ビュー モデルのフィールドを 1 つまたは 2 つ変更するとどうなりますか? ドメイン オブジェクトの残りのフィールドは、データベースでデフォルト値で上書きされませんか?

そうは言っても、最善のアプローチは何ですか？

ありがとう！

編集

だから私がつまずいているのはこれです、例えば単純なものを見てみましょうCustomer：

1)には、servicesメソッドを呼び出すサービス がありますController。CustomerServiceGetCustmoerByID

2)Serviceを呼び出してCustomerRepository、オブジェクトを取得しCustomerます。

3) ControllerAutoMapper を使用して を にマッピングしCustomerますViewModel。

4)Controllerモデルを に渡しViewます。すべてが素晴らしいです！

ここで、ビューで顧客にいくつかの変更を加え、それをコントローラーにポストして、データベースへの変更を永続化します。

この時点で、オブジェクトは切り離されていると思います。Customerでは、モデルはオブジェクトとまったく同じプロパティを持つべきでしょうか? また、表示したくないアイテムごとに非表示のフィールドを作成して、それらを永続化できるようにする必要がありますか?

オブジェクトをデータベースに保存する方法を教えてください。ビュー/モデルがオブジェクトのいくつかのフィールドのみを扱う場合はどうなりますか?

ZendFrameworkとDoctrine2を統合していて、 Serviceレイヤーを発見しています。

今、私は2つのアーキテクチャが可能であることを理解しています（私は間違っていますか？）：

• クラスにドメインロジック、つまりプロパティ+ゲッター/セッター+複雑なメソッドが含まれるモデル
• 軽量モデル。クラスにはプロパティ+ゲッター/セッターとサービスレイヤーが含まれ、ドメインロジックが含まれ、モデルクラスが変更されます。

それぞれの長所/短所は何ですか？

ドメインロジックをモデルの外部に配置してOOPを失うのは奇妙に思えるので、なぜサービスレイヤーを使用するのかわかりません。

私はWCFサービスを持っています。WCFサービスの背後には、サービス層( http://martinfowler.com/eaaCatalog/serviceLayer.html )とリポジトリ層があります。

したがって、クライアントは WCF サービス層を呼び出し、WCF サービス層 (サービス層として機能) はリポジトリ層を呼び出します。

リポジトリ層は、データベースを表すモデル (POCO) を返します。次に、サービスレイヤーは、POCOをDTOに変換してネットワーク経由で転送する必要があると思いますか? または、これらを POCO のままにしておく必要がありますか?

指定したオブジェクトをサービス レイヤーに配置したら、これをクライアント (ASP.NET MVC) に返します。クライアント (ASP.NET MVC) のコントローラーは、WCF サービスから返されたオブジェクトを VIEWMODEL にマッピングします。

WCF サービスの背後にあるサービス層とリポジトリ層など、これを正しく行っていることを知りたいですか?

そして、WCF サービスから返された実際のモデルから ViewModel を作成するコントローラーです。

また、リポジトリが WCF サービスから戻る準備ができている DTO に返す REAL モデルから変換することが本当に必要なのだろうかと思います。

オブジェクト/アイテムのコレクションを返すさまざまなメソッドを持つAPI（DLL）があります。

呼び出し元のクライアントにアイテムを返すWebサービスを作成したいと思います。

では、最善のアプローチは何ですか。APIでメソッドディレクトリを呼び出し、オートマッパーを使用してこれらをDTOSに変換し、Webサービスに返しますか？

内部的には、私のAPIはサービス/リポジトリレイヤーを使用しています。

APIから返される情報は、常に正しい形式であるとは限りません。したがって、調整を行うか、新しいメソッドを作成する必要があります。

したがって、APIを使用するのではなく、WCFサービスのデータベースディレクトリに問い合わせる独自のサービス/リポジトリレイヤーを用意するのが最善の方法です。

または、私ができるほとんどのアイテムにAPIを使用し、APIから利用できないアイテムに独自のサービス/リポジトリを実装します。

自分の作品を複製したくないのですが、実際には選択肢がありません。

たぶん、サービス/リポジトリは私のWCFと私のAPIによって共有されるべきですか？