代码之家 › 专栏 › 技术社区 › Nate CSS Guy

我应该定义一个单独的“dataContext”并传递对它的引用,还是在我最终需要它们的地方定义多个“dataContext”?

wcf-data-services silverlight wcf .net

Nate CSS Guy · 技术社区 · 14 年前

我有一个Silverlight应用程序,它由一个主窗口和几个类组成,这些类在主窗口上更新和绘制图像。我现在正在扩展它以跟踪数据库中的所有内容。

不谈细节,假设我有这样一个结构:

MainWindow
  Drawing-Surface
    Class1 -- Supports Drawing
      DataContext + DataServiceCollection<T> w/events
    Class2 -- Manages "transactions" (add/delete objects from drawing)
    Class3

每个“类”都传递一个对绘图表面的引用,以便它们可以独立地与之交互。

我开始在Class1中使用WCF数据服务,它的工作很好;但是,其他类也需要访问WCF数据服务。(我应该在主窗口中定义“dataContext”并传递对每个子类的引用吗?)

Class1需要对“事务”数据进行读访问,Class2需要对一些绘图数据进行读访问。所以我的问题是,在哪里定义数据上下文最有意义?

是否有必要:

定义“全局”WCF数据服务“上下文”对象,并在所有后续类中传递对该对象的引用?
为每个类1、类2等定义一个“上下文”实例
需要访问数据的每个方法是否都定义了自己的“context”实例并使用闭包来处理异步加载/完成事件?

这样的结构更有意义吗?将活动的“dataContext”长时间保持打开是否有危险?此应用程序的典型使用情况可能在1分钟到40分钟之间。

MainWindow
  Drawing-Surface
  DataContext
    Class1 -- Supports Drawing
      DataServiceCollection<DrawingType> w/events
    Class2 -- Manages "transactions" (add/delete objects from drawing)
      DataServiceCollection<TransactionType> w/events
    Class3
      DataServiceCollection<T> w/events

1 回复 | 直到 14 年前

Vitek Karas MSFT 14 年前

一般来说,你不应该把上下文放得太久。上下文保存对您从中获得的所有实体的引用(除非您关闭了更改跟踪),因此,如果您保留了它,那么您也将在内存中保存所有实体。如果您的访问是只读的,那么我实际上只考虑实体的生命周期(以及与之相关的内存消耗)。如果您的访问是读写的,那么如果您有两个上下文,并且从一个上下文对某个实体进行了更改,那么另一个上下文将看不到它。所以在这种情况下,您可能需要一个单独的上下文。但终生问题仍然适用。

因此,如果您知道您不会使用很多不同的实体,那么为了简单起见,我只使用一个上下文(它允许您共享实例)。如果您知道要使用很多实体,那么我会考虑偶尔删除上下文(在应用程序的某个逻辑位置)。