如何正确设计数据访问层?

发布于 2024-10-10 09:14:06 字数 639 浏览 0 评论 0原文

我有以下数据访问层(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
{

}

我将存储层与 User 类分开,以访问进一步调用任何自定义 DAL 的方法集合。

在 DAL 实现中使用 static 是否正确?

请提出更正或我可以做得更好的方法。我没有太多分层编写代码的经验。

I have the following Data Access Layer (DAL). I was wondering if it's set up correctly, or if I need to improve it?

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
{

}

I separated the storage layer from the User class to access methods collection which further call any custom DAL.

Is use of static in DAL implementation correct?

Please suggest corrections or ways I can make this better. I don't have a lot of experience with writing code in layers.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

因为看清所以看轻 2024-10-17 09:14:06

这些类都不应该是静态的。我认为您也不应该将类命名为 DAL ,因为它是数据访问层的缩写,并且类本身并不是一个层(至少在我看来)。您可以使用广泛采用的术语存储库。我建议您执行如下操作:

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);
    }
}

请注意,UserService 在其构造函数中注入了抽象类 UserRepository 的实例。您可以使用依赖注入 (DI) 框架自动为您执行此操作,例如 Windsor Castle来自城堡项目。它将允许您在配置文件或代码中指定从抽象(UserRepository)到具体实现(例如SqlUserRepository)的映射。

希望这能为您指明正确的方向,如果您需要更多信息,请询问。

None of those classes should be static. I don't think you should name your classes DAL either, because its short for Data Access Layer, and a class in itself is not a layer (in my mind at least). You can use the widely adopted term repository instead. I suggest you do something like the following:

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);
    }
}

Note that the UserService is injected with an instance of the abstract class UserRepository in its constructor. You can use a Dependency Injection (DI) framework to do this for you automatically, such as Windsor Castle from Castle Project. It will allow you to specify a mapping from abstraction (UserRepository) to concrete implementation (eg. SqlUserRepository) in a configuration file, or in code.

Hope this points you in the right direction, and please ask if you need more information.

〃安静 2024-10-17 09:14:06

我的拙见

  1. 如果用户没有任何层次结构,请使用接口而不是抽象类。
  2. 编写一个通用的 DAL,以便您可以将其重用为 DAL 层的外观。
  3. 通过 DI 框架解决具体的 DAL

My Humble Opinions

  1. Use interfaces instead of abstract class if User hasn't any hierarchy.
  2. Write a generic DAL so that you can reuse it as a facade for DAL layer.
  3. Resolve the concrete DALs by a DI framework
柏林苍穹下 2024-10-17 09:14:06

Davy Brion 在这个主题上有一组优秀的博客文章:位于 GitHub

Davy Brion has an excellent set of blog posts on this subject: located on GitHub

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文