つまり、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）は、彼らが言うとおりに機能します。
私の同僚は、ビジネスリポジトリが必要かもしれないと思っていましたが、少し不格好だと思いました。何かご意見は？
これを解決するには、ビジネスサービスレイヤーを作成しました。このようにして、ビジネスサービスレイヤーを通じて機能にアクセスできます。ビジネスレイヤーは、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);
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加