3

リポジトリ パターンを使用して ORM を抽象化するコードをよく見かけます。なぜこれが行われるのですか？ORM はすでに抽象化されており、リポジトリ自体として機能していませんか?

の間に大きな違いはありますか

public class EmployeeRepo 
{
    GetById(int id) { //Access ORM here };
}

データの消費:

public class MyController{
    private EmployeeRepo = _Repo = new EmployeeRepo();

    public ActionResult ShowEmployee(int id)
    {
        var emp = _Repo.GetById(id);
        //Versus
        var emp = ORM.Where(e => e.Id == id);

        return View(emp);
    }
}

ORM が既に提供しているものを再作成する作業を行う必要があるのはなぜですか?

4

3 に答える 3

3

私はそれが古い質問であることを知っていますが、件名について話すのは非常に興味深いものです.

ORM を直接使用する方が簡単であり、単純なプロジェクトでは正しいことかもしれないことに同意します。

しかし、長期にわたる複雑なシステムを開発している場合、ビジネス ロジックで ORM に直接依存するということは、何千もの場所でその ORM に依存することを意味します。これは、その ORM の重大な変更のため、または単に別の方法を行うことにしたため、将来的に必然的に問題を引き起こします。

したがって、ORM を抽象化することは、ORM を簡単に切り替える機能ではなく、プロジェクトを外部の依存関係から分離することです (一般的な ORM の変更を壊す可能性は、その複雑さと継続的な開発のために十分に高いです)。さらに、そのような分離されたアーキテクチャを使用すると、ボーナスとしてプロジェクトの優れたテスト容易性が得られます。

自分でその抽象化を行いたくない場合は、それを支援できるプロジェクト (例: Antler ) があります。もちろん、それはあなたがそのフレームワークに順番に依存することを意味しますが、そのようなフレームワークは、実際には決して変更されない抽象化と統一された構文を提供する、さまざまな ORM (およびその ORM の重大な変更) を処理する責任を負います。

于 2014-12-30T13:01:51.957 に答える
2

多くの場合、これはオーバーエンジニアリングの結果ですが、ORM を切り替える可能性がある場合は、制御するコントラクト AKA パブリック/内部メソッドを持つクラスに ORM をカプセル化することをお勧めします。このようにして、クラスを変更するだけで (またはインターフェイスにプログラムされている場合は別のクラスを挿入して)、ORM を切り替えることができます。それ以外の場合は、すべてのコードからの直接の ORM 呼び出しを実装解除し、代わりに新しい呼び出しを再実装する必要があります。これは、プロジェクトの複雑さに応じて、数百行から数千行になる可能性があります。

于 2013-06-10T16:22:59.043 に答える