代码之家 › 专栏 › 技术社区 › Jagmag

如何缓存业务对象以避免往返数据库?

business-objects caching frameworks design-patterns

0

Jagmag · 技术社区 · 14 年前

我已经为自己准备了一个现有的应用程序——它尝试自己做很多事情,而且大部分都做得很糟糕!

此应用程序是一个ASP.NET 3.5 Web应用程序,具有典型的ui->业务--gt;dal类型的模式。

我面临的问题是,当多个用户请求相同的信息时,即使只是为了查看它,同样的业务对象也会被实例化,同样的数据会一直从数据库中检索。

目前,这些对象没有单点实例化,比如工厂实现或这些行上的某些内容。对象实例化只是散布在各处。

我一直在考虑的一个选项是在工厂中封装整个实例逻辑,并在工厂中构建逻辑来缓存对象并相应地返回。

我正在考虑的另一个选择——我在过去的一个项目中使用过CSLA,我想我记得它曾经用于缓存业务对象。然而,我并不知道它是如何实现这一目标的。我正在考虑使用一些像CSLA这样的框架,它为缓存我的业务对象提供了这样的工具。

但是,上述两个选项都是非常具有侵入性的,如果不完全修改,将涉及到整个业务层,这是我的一个主要问题,因为没有(read zilch,nada,zero,the big-o)对代码的任何部分进行自动单元测试。

我想知道的是:

不,退出公司不是一个选择-至少现在还不是!-)

2 回复 | 直到 14 年前

1

3

msw 14 年前

通过分析找出最坏的罪犯 memoize 他们的电话。

对评论的回应

memoization与使用模式无关,它实际上只是将昂贵的操作(访问数据库)替换为更便宜的核心查找。使用模式肯定会影响 有效性 系统内的记忆化,但不通知记忆化代码是如何编写的。

下面是一个便宜的例子:

define square_root(n):
   if cache[n] does not exist then
      cache[n] = compute_root(n)

   return cache[n]

这意味着你第一次打电话 square_root(1729) 计算根需要时间。所有后续呼叫 方根(1729) 只需要高速缓存查找。如果再也不进行该调用,您将浪费缓存时间和空间。

因此,记忆 square_root 只要求有一个唯一的结果 n . 优化是否有用是实际使用的一个因素。

2

0

marr75 14 年前

缓存被烘焙到ASP.NET中,在.NET 4.0中(我知道您还没有切换),相同的缓存可以在ASP.NET类的任何地方、内部或外部使用。

您仍然需要控制对象实例化。我建议使用依赖注入框架。我喜欢autopac,这将允许您从某个依赖注入的提供程序请求新对象,并决定如何处理该提供程序中的缓存。

您来找我们时遇到了一个问题,我给您3个(学习如何使用和实现依赖项注入框架,学习如何使用ASP.NET缓存,使用缓存策略来解决性能问题),但这可能是您最灵活和最可维护的赌注。