1

私の最後のアプリは、UoW、DI、IoC、Repository Pattern、Factory など、あらゆる種類のものを実装していて、きちんとしているように見えましたが、メンテナンスとデバッグが面倒でした。

私は最近のアプリで逆のアプローチをとっています.DIもIoCもUoWもありません.MVC、サービスレイヤー、DBのみです. 私はおそらくリポジトリ パターンについてすべて間違っていると考えていますが、私が行った読み取りでは、2 つの懸念を分離しておくために、ビジネス ロジックではなく Db アクセスのみを担当していることを示唆しています。

リポジトリ パターンの実装では、サービス レイヤーの多くを複製しているように感じます。たとえば、私の UserService クラスには、次のものがあります。

    public void UpdateAboutMe(AboutMeDto request)
    {
        using (var db = CreateContext())
        {
            var user = db.Users.FirstOrDefault(s => s.Username.Equals(request.Username, StringComparison.OrdinalIgnoreCase));
            if (user != null)
            {
                user.AboutMe = request.AboutMe;
                SaveChanges(db);
            }
            else
            {
                throw new InvalidDataException("Null User");
            }
        }
    }

このようにして、サービスはオブジェクトを取得し、単一のフィールドを更新し、変更を DB にコミットし、コンテキストを破棄します。

私の UserService には、次のような他のメソッドがあります。

  • GetUserByUserName
  • GetUserById
  • GetUsersWithChildEntities
  • GetUsersWithoutChildEntities (前者よりも高速ですよね?)
  • ユーザーサムネイルの更新
  • UpdateUserBio
  • UpdateUserInterests

これらのすべてに、対応する Repo メソッドが必要ではないでしょうか?

リポジトリ メソッドを実装すると、上記のサービスは次のようになります。

public void UpdateAboutMe(AboutMeDto request)
        {
            return _userRepository.UpdateAboutMe(request);
        }

これはきれいに見えますが、物を移動しているだけなので、それほどきれいではありません.Getメソッドの1つを変更して子エンティティを含めることにした場合は、レポで別のメソッドを作成し、インターフェイスを更新する必要があります、サービス メソッドから直接行うのではなく、サービス メソッドを更新します。

上記で示した限られた理解に基づいて、Repository Pattern を実装する必要があるかどうかを学ぶことに基本的に興味があります。アプリに垂直方向の複雑なレイヤーを追加するか、サービスレイヤーを少し強化するだけのようです。

IMO - EF の遅延読み込みとフィールドごとの更新を使用すると、リポジトリ パターンのオーバーヘッドがはるかに大きくなるようです。

そして、この場合、私は TDD にあまり詳しくないので、可能であれば、テスト容易性を方程式から除外したいと思います。

4

2 に答える 2

0

TDD、IoC/DI、または再利用性に関心がない場合は、余分なレイヤーを用意する必要はありません。各レイヤーには目的がありますが、その目的がなければそのレイヤーは必要ありません。

ただし、サーバーの停止中に人が死亡し始めると、書き直しが難しくなります。

于 2013-11-08T00:12:49.543 に答える