我遇到的疑问是关于在winform 应用程序中实现DAL和BLL访问层期间静态方法的使用。
我知道这里有很多关于这个主题的文章，但我没有找到任何回复我具体问题的文章。
简要介绍：我正在开发一个Windows表单应用程序，该应用程序将被许多用户使用(每个用户在虚拟机上都有他们的帐户 - 所以基本上应用程序的每个实例将由不同的用户帐户执行(。 由于我不需要保留许多对象的状态，因此我决定使用(直到现在我的意思是某些操作(静态方法，特别是在 DAL 和 BLL 中执行以下操作：GetUserProfiles、GetProfileByUserName、AddNewUser、UpdateUserByUserID 等......或者使用一些信息(例如：当前正在运行应用程序的用户、来自数据库的查找数据等(保持应用程序的状态，这些信息预计在应用程序的整个执行过程中保持不变。
我的问题/疑问：使用静态方法实现对数据库的这些访问部分是否正确，因为只需要检索信息，并且在我看来，不需要状态，因为每次执行它们时都像新的执行一样，以前的状态是不必要的？
在您看来，我的思维方式和方法是否正确，还是我做错了我现在看不到的事情？
谢谢你，每个人都会回复并给我一个更好的建议。
尽管这个问题的答案在很大程度上取决于您的应用程序/安全性/性能/时间的大小......但对于大多数专业开发人员来说，它被称为"最佳实践"女巫问题。
也有人可能会说只是 KISS(保持简单和愚蠢(，但如果你要考虑未来，你应该继续遵循最不了解的 DAL 最佳实践。
假设明年你的老板命令你在代码中使用实体框架，那你会怎么做？ 如果你的代码只是一个成熟的代码，则需要繁重的工作负荷才能将所有内容更改为 EF。 或者，如果您更改数据库引擎 Oracle/MySql/SqlServer，会发生什么？ 那么如果你那里有很多代码，你就会遇到一个很深的麻烦。
我建议至少使用一个接口，并为您的 DAL 使用工厂设计模式，如果你不打算为复杂的模式而苦苦挣扎。
另一件要提到的是，使用静态类，您正在使每个用户的DAL单线程对于Win Form应用程序来说不是很好。
所以如果你想 灵活性和多线程能力 为您的应用程序;不是最佳实践，但如果您只是希望应用程序在那里工作，那么您就是。
静态成员(方法、属性等(不能从面向对象中受益，即多态性、继承、接口实现等。
如果您使用的是存储库模式，则可以概括事物并保留向特定存储库添加特定方法的能力。存储库可以描述为：
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接口中未定义的方法。
如果希望它更加静态，可以将接口实现为单例。