1

私は mvc4 Web サイトに汎用リポジトリと作業単位パターンを使用しています。

今、システムのユーザーを削除したいという状況があります。削除コードでは、他のテーブル (コメント、アクセス権など) のエントリをさらに削除する必要があります。

最も簡単な解決策は、UserRepository継承するを作成しGenericRepository<User>、delete メソッドを変更して、他のテーブルのデータを削除することです。しかしUserRepository、それは、独自のリポジトリ クラスを持つ必要がある他のテーブルにアクセスすることを意味しますよね?

ビジネス ロジックとリポジトリの間にあるサービス レイヤーについて読みました。

ここでのベストプラクティスは何ですか?また、サービス層の実装はどのように見えますか?

UserRepositoryまた、サービス レイヤーを使用する場合や、汎用リポジトリのみを使用してサービス クラスでロジックを実行する必要がある場合など、カスタム実装リポジトリを使用する必要はありますか?

コード例:

class UserRepository
{
    public void Delete(User entity)
    {
        var userComments = Context.UserComments.Get(comment => comment.UserId == entity.Id);

        foreach (var comment in userComments)
        {
            Context.UserComments.Remove(comment);
        }

        //
        // same for access rights here
        //

        Context.Users.Remove(entity);
    }
}
4

3 に答える 3

2

使用する

.WillCascadeOnDelete(true);

の上modelBuilder

サービスに関するご質問にお答えするため。理想的には、リポジトリが取得したエンティティ/オブジェクトに対して追加のロジックを実行するサービスが必要です。この場合、これはリポジトリの責任であるため、サービスが行を削除することは実際には望ましくありません。

サービスは良いです。MVC では、コントローラーからサービス メソッドを呼び出します。理想的には、簡単にテストできるインターフェイスです。

于 2013-05-28T21:09:03.537 に答える
0

あなたが言ったように、サービス層はビジネスロジックとリポジトリを分離するのに役立ちます. ここでの主なアイデアは依存性注入です

public interface IUserService
{
    public void Delete(User entity);
}

//
// This class would be used Linq to Entities 
public class LinqUserService : IUserService 
{
    public void Delete (User entity)
    {
    }  
}

// 
// This class would be used Sql command
public class SqlUserService : IUserService
{
    public void Delete (User entity)
    {
    } 
}
于 2013-05-28T21:09:57.983 に答える