C# Winform - DAL 和 BLL - 使用静态方法好吗？

Question

我遇到的疑问是关于在winform应用程序中实现DAL和BLL访问层期间使用静态方法的问题。

我知道这里有很多关于这个主题的文章，但我没有找到任何可以回答我的具体问题的文章。

简要介绍：我正在开发一个 Windows 窗体应用程序，该应用程序将被许多用户使用（每个用户在虚拟机上都有自己的帐户 - 所以基本上每个应用程序实例都将由不同的用户帐户执行）。 因为我不需要保留许多对象的状态，所以我决定使用（直到现在我的意思是某些操作）静态方法，特别是在 DAL 和 BLL 中执行以下操作：GetUserProfiles、GetProfileByUserName、AddNewUser、UpdateUserByUserID 等...或使用某些信息（例如：当前正在运行应用程序的用户、从 DB 中查找数据等）保持应用程序的状态，这些信息预计在应用程序的整个执行过程中保持不变。

我的问题/疑问：使用静态方法实现对数据库的这些访问部分是否正确，因为它们只是为了检索信息而需要，并且在我看来，不需要状态，因为每次它们都会执行它就像一个新的执行和以前的状态是不必要的？

你认为我的思维方式和方法是正确的，还是我做错了我目前看不到的事情？

谢谢大家的回复，并给我一些更好的建议。

Answer 1

虽然这个问题的答案很大程度上取决于您的应用程序/安全性/性能/时间的大小......但对于大多数专业开发人员来说，这被称为“最佳实践”，这很重要。

也有人可能会说KISS（保持简单和愚蠢），但如果您要考虑未来，您应该继续遵循最不为人知的 DAL 最佳实践进行设计。

假设明年你的老板命令你在代码中使用实体框架，那么你会怎么做？如果您的代码只是一个成熟的代码，则需要繁重的工作量才能将所有内容更改为 EF。或者如果您更改数据库引擎 Oracle/MySql/SqlServer 会发生什么？如果那里有很多代码，那么你就有很大的麻烦了。

如果您不想与复杂的模式作斗争，我建议至少将接口与 Factory Design Patterin 结合使用作为您的 DAL。

另一件要提的事情是，使用静态类使每个用户的 DAL 单线程对于 Win Form 应用程序来说并不是很好。

因此，如果您希望应用程序具有灵活性和多线程能力，这不是最佳做法，但如果您只是希望应用程序在那里工作，那么您就是。

Answer 2

静态成员（方法、属性等）无法从面向对象中受益，即多态、继承、接口实现等。

如果您使用的是存储库模式，您可以概括事物并保留将特定方法添加到特定存储库的能力。存储库可以描述为：

public interface IRepository<T>
{
    T GetById(int id);
    List<T> GetAll();
    void Create(T entity);
    void Delete(T entity);
    void Update(T entity);
}

这只是一个示例，您可以根据自己的需要进行定制。

作为灵活性的示例，假设 CSV 导出器接受具有方法的存储库

public void Export<T>(string file, IReporistory<T> repository)
{
    ...
    List<T> result = repository.GetAll();
    ...
}

在实现此接口的UserProfileRepository 中，您仍然可以添加未在接口中定义的方法GetProfileByUserName。

如果您希望它更静态，可以将接口实现为singletons。