8

だから私はDAO、DTO、およびBOを持っています。次のコードが結果です。

// Instantiate a new user repository.
UserRepository rep = new UserRepository();

// Retrieve user by ID (returns DTO) and convert to business object.
User user = rep.GetById(32).ToBusiness<User>();

// Perform business logic.
user.ResetPassword();
user.OtherBusinessLogic("test");
user.FirstName = "Bob";

// Convert business object back to a DTO to save to the database.
rep.Save(user.ToDataTransfer<Data.DTO.User>());

だから私は懸念を分離しようとしていますが、このコードの「変換」を取り除きたいです。「変換」は、実際には拡張オブジェクトとしてビジネス ロジック レイヤー (DTO レイヤーはビジネス ロジック レイヤーについて何も知らない) に配置されます。DTO自体は明らかにデータを保存するだけで、ビジネスロジックはまったくありません。UserRepository は DAO を呼び出し、GetById の最後で AutoMapper を使用して DAO から DTO にマップします。「変換」(ToBusiness および ToDataTransfer) は、彼らが言うように正確に行います。

私の同僚は、ビジネス リポジトリが必要かもしれないと考えていましたが、それは少し扱いに​​くいかもしれないと考えていました。何かご意見は？

4

3 に答える 3

9

ここでの唯一の混乱の原因は、 と の呼び出しが必要な理由ToBusiness<User>()ですToDataTransfer<Data.DTO.User>()。

リポジトリの責任は、データ管理を処理することです。実装の詳細 (およびビジネス オブジェクトとデータ オブジェクト間の変換) を非表示にする必要があります。

Aは、キャストを必要とせずにaUserRepositoryを返す必要があります。User

また、キャストせずUserRepositoryに a を永続化できる必要があります。User

すべてのキャストがリポジトリで処理され、コードが次のように読み取られた場合、コードははるかにクリーンになります。

UserRepository rep = new UserRepository();

User user = rep.GetById(32);

// Do Work Here

rep.Save(user);
于 2010-01-19T20:22:18.647 に答える
5

これは、ビジネス サービス レイヤーを作成することで解決しました。このようにして、DAL をクエリして DTO を返すリポジトリを使用するビジネス サービス レイヤーを介して機能にアクセスできます。DTO は、DAL によって入力されることで目的を果たし、データをビジネス層に転送する (ビジネス オブジェクトに変換する) のに役立ちます。

したがって、図は次のようになります。

DAL -> リポジトリ (DTO を返す) -> サービス (BO を返す)

それは非常にうまく機能し、リポジトリ自体からビジネスロジックを抽象化するサービスレイヤーにビジネスロジックを配置できます。サンプルコード:

// UserService uses UserRepository internally + any additional business logic.
var service = new UserService();
var user = service.GetById(32);

user.ResetPassword();
user.OtherBusinessLogic("test");
user.FirstName = "Bob";

service.Save(user);
于 2010-01-20T19:48:57.993 に答える
1

DTO が BO に変換されるのを見るのはこれが初めてです。私は通常、BO クラスまたはメソッドによって消費される DTO を送信します。BO が完了し、DTO への変更を保存する必要がある場合、BO はそれを DAL に送信し、保持します。

于 2010-01-19T20:21:03.863 に答える