0

私はEntityFrameworkを使用して2番目のプロジェクトに取り組んでいますが、コードが適切なコーディング慣行を下回っているかどうかについて、いくつかの意見を読みたいと思います。

私が提案するアーキテクチャは次のとおりです。

ここに画像の説明を入力してください

したがって、Webサイトはビジネスロジックを呼び出し、ビジネスルールはそこで評価されます。DALFacadeを呼び出すと、db2またはsqlサーバーにアクセスしているかどうかに関係なく、上位層には表示されません。

EF DALは、データベースとの通信を担当するCODEFIRSTアプローチです。エンティティクラスライブラリは、pocoクラスを含むプロジェクトです。ユーティリティは自明ですが、ActiveDirectoryからプロパティを読み取るようなコードを配置する場合があります。

だからここに私のコードがあります、私はそれをできるだけ単純化しました

1ページ：

protected void BtnSubmitRequestClick(object sender, EventArgs e)
    {
        var ecoBonusWorkflow = new EcoBonusWorkflow
                                   {
                                       IsOnHold = true
                                   };

        BusinessLogic.EcoBonusRequestSave(ecoBonusWorkflow);
    }

ビジネスの論理：

public static class BusinessLogic
    {
        public static void EcoBonusRequestSave(EcoBonusWorkflow ecoBonusWorkflow)
        {
            if (true)
            {
                DalFacade.EcoBonusRequestSave(ecoBonusWorkflow);
            }
        }
    }

DALFacade：

 public static class DalFacade
    {
        private  static readonly UnitOfWork UnitOfWork = new UnitOfWork();

        public static void EcoBonusRequestSave(EcoBonusWorkflow ecoBonusWorkFlow)
        {
            UnitOfWork.EcoBonusWorkflowRepository.InsertEcoBonusWorkflow(ecoBonusWorkFlow);
        }
    }

次に、EF Dalクラスライブラリで、従来のEF4.1コードファーストアプローチを使用します。リポジトリパターンと作業単位も使用しました。

どんな観察も歓迎します

4

1 に答える 1

2

「ユーティリティ」を含めることは私には非常に奇妙に思えます。他のすべては、それが何をすべきかというかなり特定の設定でまともな名前が付けられています。そうすれば、この漠然とした名前の「ユーティリティ」のブロックができます。

これは特定のコーディング標準ではありませんが、可能な限り「ユーティリティ」をトップレベルのアーキテクチャに組み込むことは避けたいと思います。すべてのプロジェクトには、「helpers」または「utilities」という名前のフォルダがあり、他の場所にすぐには収まらないように見える大量の雑多なコードのダンプになってしまいます。これはまさに技術的負債とスパゲッティコードが始まる方法です。

あなたがプロジェクトの唯一の開発者でない限り、あなたが何を提示しても、それはおそらく起こるでしょうが、それでも私はそれを正当化することを避けます。

また、あなたの素早い汚いクラスに静的クラスが含まれていることは私を驚かせます。静的コードがテスト容易性を損なうという事実を除けば、EntityFrameworkはスレッドセーフではありません。スレッドセーフな方法で使用するのはあなた次第です。したがって、マルチスレッドまたはコプロセッシングが実行されている場合、DALFacadeはランダムに大量のエラーをスローし、大きな頭痛の種になります。

また、デザインに依存性注入の許容範囲がありません。これも、コードのテスト可能性に影響します。

編集：OK、これらはStackの譲歩ではなかったので、依存性注入のアイデアを紹介する時が来ました。

基本的に、静的クラスを呼び出すときなど、何かを他の何かに直接依存させるときはいつでも、これら2つのことを結び付けています。一方の部品は、もう一方の部品を変更または交換せずに交換することはできなくなります。これは、リファクタリングを行い、非常に大きな問題を変更するため、悪いことです。代わりに、これらの依存関係を「緩く結合」して、すべてを壊すことなくパーツを変更できるようにします。C＃/。NETでは、ほとんどの場合、これはインターフェイスを使用して行います。

したがって、「DALFacade」を使用して直接渡す代わりに、次のような効果があります。

interface IDalFacade
{
    int DoAThing();

    bool DoAnotherThing();
}

class DalFacade : IDalFacade
{
    public int DoAThing()
    {
        return 0;
    }

    public bool DoAnotherThing()
    {
        return false;
    }
}

次に、次のようにビジネスロジックで使用できます。

class BusinessLogic : IBusinessLogic
{
    public IDalFacade DalFacade { get; private set; }

    public BusinessLogic() : this(new DalFacade())
    {}

    public BusinessLogic(IDalFacade dalFacade)
    {
        this.DalFacade = dalFacade;
    }

    public void LogicTheThings()
    {
        this.DalFacade.DoAThing();
    }
}

DalFacadeが完全にゴミ箱に入れられた場合でも、突然、別の目的で2つ必要になった場合でも、問題はなくなりました。または、実際には、DalFacadeが渡された場合でも、IDalFacade契約を満たしている限り、まったく問題ありません。パラメータなしで呼び出すこともできますが（特定の実装を想定しているだけです）、これでも理想的ではありません。理想的には、NinjectやStructureMapなどの依存性注入ライブラリを使用することをお勧めします。これにより、特定の変更をさらに簡単に行うことができます。

これは、コードの単体テストを試みるときにも役立ちます。これは、前述したように、実際のDalFacadeでさえも実行する必要がないためです。IDalFacadeコントラクトを満たすものを（ RhinoMocksなどを使用して）モックアウトするだけで、プロジェクト内の他のコードとはまったく別にすべてのコードをテストできます。

于 2012-05-07T16:07:07.160 に答える