优点/缺点是增加存储库实例的范围?

时间:2009-03-19 23:24:29

标签: c# asp.net performance

这个问题的标题写得不是很好。抱歉'回合那个。

我很好奇将方法中的对象实例的范围扩展到类级别的优缺点是什么。

作为一个具体的例子,我有一个非静态服务类,它包含对用于管理CRUD活动的存储库类的访问,以及一些不一定与其他业务逻辑很好地混合的其他任务。当我构建它时,每个方法都创建它自己的存储库实例。假设平均流量(没什么大的),我想知道在服务类的构造函数中创建此存储库的类级实例是否有任何好处,而不是我当前使用的方法级别范围。此应用目前不使用DI,但这可能是一种选择。我也在考虑让这个课程保持静态,但在选择之前我还有其他一些障碍可以跳过。

提前致谢。

2 个答案:

答案 0 :(得分:3)

您的代码甚至还没有工作,而且您已经在优化了。停止!让您的代码工作,然后分析性能并针对您实际所具有的性能问题进行优化,而不是您认为可能会遇到的问题。

不要猜错并解决错误的问题,或者让事情变得更糟!

答案 1 :(得分:0)

+1到John Saunders

除此之外,让我评论一下:

  

我想知道在服务类的构造函数中创建此存储库的类级实例是否有任何好处,而不是我正在使用的方法级别范围

创建存储库类是否昂贵? “昂贵”我的意思是有一个分析器向您显示它对您的应用程序的运行时间做出了显着贡献。

如果是这样,您可能希望将其缓存在实例变量中。如果没有,请保持本地化。一旦将它提升为实例变量,就会给自己带来许多问题,例如

  • 谁先创建它?
  • 当2个线程访问同一个实例时会发生什么?
  • 谁清理它?有没有人? (using语句不再是一个选项)
  • 这是否意味着你需要为你的班级写一个终结者? (啊)
  • 如果需要参数来创建它,谁来提供它们?
  • 如果需要更改或在方法调用之间重新创建会发生什么?

旧的“全局变量是邪恶的”引用是恕我直言,这是“共享国家是邪恶的”最常见的情况,这是实际问题。