良いコーディング慣行

Question

私はEntity Frameworkで私の2番目のプロジェクトに取り組んでいます。だから、ウェブサイトは、ビジネスロジックを呼び出して、ビジネスルールがそこに評価され

：

私の提案するアーキテクチャはこれです。 それは、DALFacadeを呼び出します.DALFacadeは、db2またはSQLサーバーにアクセスしているかどうかにかかわらず、上位層には表示されません。

データベースとの会話を担当するEF DAL、CODE FIRST Approach。 エンティティクラスライブラリは、pocoクラスを持つプロジェクトです。 ユーティリティそのものを説明すると、アクティブなディレクトリからプロパティを読み込むようなコードを記述することがあります。 SOここ

は私のコードは、私はそれが同じくらいのように簡略化され、私でし

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 cl私は伝統的なEF 4.1コード第一アプローチを使用します。 私はRepository PatternとUnit of Workも使用しました。

どれ観察が

Answer 1

を歓迎している「ユーティリティ」を含めることは、私には非常に奇妙なようです。他のすべてはまさにそれがすべきことのかなり特殊な設定でうまく命名されています。そして、あなたはこの漠然とした名前の「ユーティリティ」ブロックを持っています。

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

あなたがプロジェクトの唯一の開発者でない限り、あなたが提示しているものに関係なく、おそらく起きるでしょうが、それにもかかわらず私はそれを正当化しようとしません。

また、クイックダーティーに静的なクラスを含めると私に警告します。静的コードがテスト容易性を傷つけるという事実を除いて、Entityフレームワークはではなく、スレッドセーフです。スレッドセーフな方法で使用するのはあなた次第です。マルチスレッドやコプロセッシングをすべてDALFacadeで行っている場合は、ランダムに大量のエラーが発生し、巨大な頭痛になります。

私はあなたのデザインに依存性インジェクションを考慮していません。これはコードがどのようにテスト可能かを示しています。

編集：OK、これはStackの譲歩ではありませんでしたので、今度はdependency injectionというアイデアを紹介します。

基本的に、静的なクラスを呼び出すときなど、何かを直接他のものに依存させるときは、これらの2つのものを結びつけています。 1つの部品は、もう一方の部品を修正または交換することなく、もはや交換可能ではない。これはリファクタリングを行い、非常に大きな問題を変更するため、悪いことです。あなたが代わりにしたいのは、これらの依存関係を「疎結合」することで、すべてを壊すことなくパーツを変更することができます。 C＃/ .NETでは、主にインターフェイスでこれを行います。あなたがそのようにのようなあなたのビジネスロジックでそれを使用することができ

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」を有すると直接の周りにそれを渡すので、あなたの代わりにの効果に何かを持っているでしょう

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

これは、私が言ったように、実際のDalFacadeを必要としないので、コードを単体テストしようとするときにも便利です。 （RhinoMocksのようなものを使用して）IDalFacade契約を満たすものを模倣するだけで、すべてのコードをプロジェクト内の他のものと完全に別々にテストすることができます。