2011-01-06 3 views
7

私は以下のデータアクセスレイヤー(DAL)を持っています。私はそれが正しく設定されている場合、または私はそれを改善する必要があるのだろうか?データアクセスレイヤを適切に設計するにはどうすればよいですか?

public class User 
{ 

} 

//Persistence methods 
static class UserDataAccess 
{ 
    UsersDAL udal = // Choose SQL or FileSystem DAL impl. 


    InsertUser(User u) 
    { 
     // Custom logic , is 'u' valid etc. 

     udal.Insert(u); 
    } 
} 

abstract class UsersDAL 
{  
    GetUserByID(); 
    InsertUser(u); 
    ... 
} 

// implementaitons of DAL 

static class UsersSQLStore : UsersDAL 
{ 

} 

static class UsersFileSystemStore : UsersDAL 
{ 

} 

カスタムDALをさらに呼び出すメソッドコレクションにアクセスするために、ストレージクラスをUserクラスから分離しました。

staticのDAL実装での使用は正しいですか?

これを改善する方法や改善方法をご提案ください。レイヤーでコードを書く経験はあまりありません。

+2

あなたの質問に完全に綴る時間がかからない場合は(PleaseではなくPlを使用してください)、あなたの質問に答えるか、お手伝いする時間をどのように取ると思いますか? –

+7

@George、それは誰かを傷つけるかどうか分かりませんが、あまりにも多くの人が読んでいる人を救うためには、定期的に使用しています。代わりに、私は私の例を書き留めることに集中しました。それは私が人々の時間と彼らの反応を気楽にすることを意味しません。 –

+0

LLBLGenやDapperのようなORMを使用する代わりに、なぜこれをしたいですか?ホイールを再構築する必要はありません。 –

答えて

12

なしstaticないはずDIフレームワークによってコンクリートDALSを解決。私はあなたのクラスをDALと名付けるべきではないと思います。なぜなら、そのデータアクセスレイヤーの短さと、それ自身のクラスは少なくとも私の考えではレイヤーではないからです。代わりに広く採用されている用語repositoryを使用することができます。 UserServiceはそのコンストラクタで抽象クラスUserRepositoryのインスタンスを注入されていることを

public class User{ 

} 

public abstract class UserRepository{ 
    public abstract void InsertUser(User user); 
} 

public class SqlUserRepository : UserRepository{ 
    public override void InsertUser(User user) 
    { 
     //Do it 
    } 
} 

public class FileSystemUserRepository : UserRepository{ 
    public override void InsertUser(User user) 
    { 
     //Do it 
    } 
} 

public class UserService{ 
    private readonly UserRepository userRepository; 

    public UserService(UserRepository userRepository){ 
     this.userRepository = userRepository; 
    } 

    public void InsertUser(User user){ 
     if(user == null) throw new ArgumentNullException("user"); 
     //other checks 
     this.userRepository.InsertUser(user); 
    } 
} 

注:私は、あなたが以下のような何かを示唆しています。あなたは自動的にDependency Injection(DI)フレームワークを使用して、Castle ProjectのWindsor Castleなどを自動的に使用できます。これにより、構成ファイルまたはコード内の抽象化(UserRepository)から具体的な実装(たとえば、SqlUserRepository)へのマッピングを指定できます。

これは正しい方向を指していると思いますので、詳細が必要かどうか尋ねてください。

+0

それはテンプレートパターンです。あなたはホフマンとジャニによって提案されたように、ほとんど変化がない正しい方向にあります。 – hungryMind

+0

大きな説明。なぜshoudlnt私は静的を使用しますか?リポジトリではない場合は、UserServiceのために静的にすることができますか? 1つ以上(DALと無関係かもしれない):既存のユーザーが挿入しようとした場合、誰がこのチェックを行うべきか、UserServiceまたはUserクラス自体がコンストラクタを介して(それが新しい時にabtの存在を知らないので) –

+0

@Munish Goyal、それが必要ないので 'static'を使うべきではありません。不適切に使用された場合、 'static'はアプリケーションに不必要な状態をもたらし、デバッグが困難になり、最も重要なことに、自動的にテストするのが難しくなります**。おそらく 'static 'の正確な意味をhttp://msdn.microsoft.com/en-us/library/98f28cdx%28vs.71%29で読んでみたいです。aspx –

6

マイハンブル意見

  1. 代わりに抽象クラスを使用するインターフェースユーザーは、任意の階層をしていない場合。
  2. DALレイヤのファサードとして再利用できるように汎用DALを作成します。
  3. これらのクラスの
関連する問題