所以我今天遇到了这个问题,我找不到一些有意义的解释是否有一些非主观的理由在数据库交互时使用静态方法.
现在我正在开发一个项目,通过存储过程完成所有事情,例如我有一些常规方法,如:
public void Delete(int clientID) { //calling store procedure }
要么
public void Save(int clientID) { //calling store procedure }
但我也有:
public static Client GetByID(int id) { //calling stored procedure }
要么
public static int AddNew(string firstName, string lastName...) { //calling store procedure }
因为我已经工作.NET
了大约9个月而且我一直在使用Entity Framework
,Repository Pattern
我无法回忆任何地方或任何使用静态方法的代码.不适用于标准CRUD
操作,也不适用于与数据库相关的更具体任务.
这是与访问数据库的特定方式有关的东西,是一些可以提供(甚至是非常小的)性能提升的实践,或者它只是开发人员的方法,我不应该在何时不在我的数据库中使用静态方法相关的方法?
在数据访问层的特定情况下,我会出于一个简单的原因避免静态方法...耦合.
静态方法无法实现接口,实例方法可以.通过使用静态方法,基本上坚持不对编码到接口而是编码到实现.因此,使用这种数据访问层一切都需要对这个这个特定时刻数据访问层.
没有替代实现,没有测试存根,根本没有依赖性反转.业务逻辑具有指向基础结构关注点(数据访问层)的依赖关系箭头,而这应该是相反的方式.
此外,这似乎至少带来了处理资源问题的更大风险.这可能不是这种情况,但它很容易成为案例.如果开发人员有一个明智的想法将常见的代码行提取到类级静态方法和属性中会怎样?有点像Connection
还是DBContext
反对呢?这将创建一些非常有趣且非常难以调试的运行时错误.
另一方面,如果存储库是实例,那么它们可以简单地实现IDisposable
并确保正确处理任何类级别对象.
持续进行中(我想我有更多的异议,比我想象的设计),这种感觉非常反直觉我来自一个面向对象的意义.也许这只是个人偏好,但这将把本来就是"存储库对象"转变为"数据库助手方法的倾销场".
在这样的系统中,随着开发人员在不考虑整体架构的情况下制定快速解决方案来满足需求,我预计随机一次性方法的数量会随着时间的推移而显着增长.而不是一致且管理良好的一系列对象,很可能最终会出现一个臃肿且难以理解的代码库.