IList <item>集合类访问数据库</item>

时间:2010-03-23 14:19:39

标签: c# database caching collections class-design

我有一个用户数据库。 用户有项目。

这些项目可以积极改变。 如何访问集合类型格式的项目? 对于用户,我在实例化时填充所有用户属性。 如果我在实例化时加载用户的项目,并且项目发生变化, 他们将有旧数据。

我在想,也许我需要一个ItemCollection类,并且在用户类之外有一个字段/属性,这样就可以遍历所有用户的项目,我可以使用foreach循环。

所以,我的问题是,使用某种集合从数据库访问项目的最佳实践/最佳方法是什么?在访问特定项时,它需要获取最新的数据库信息,当用户执行foreach循环时,必须提供最新的项目信息。

即。我正在尝试做什么

Console.WriteLine(User.Items[3].ID); returns 5.
//this updates the item information and saves it to the database.
User.Items[3].ID = 13; 

//Add a new item to the database.
User.Items.Add(new Item { id = 17});

foreach (Item item in User.Items) {
    //this would traverse all items in the database.
    //not some cached copy at the time of instantiation of the user.
}

编辑:抱歉,我写这个问题有点不对劲。 我目前正在使用Linq,但我有Classes映射到业务对象。 当我对业务对象进行遍历时,我希望它转到Linq datacontext并获取信息。

当我实现一个实现接口IList的新类“ItemCollection”时, 我需要做什么才能让它返回项目?

使用User.Items [3],在公共Item中实现这个[int index]方法。 index方法是否应该使用linq.Skip运算符来获取数据库中项目的索引?

我对将业务对象集合映射到数据库感到困惑。

4 个答案:

答案 0 :(得分:1)

虽然可以这样做,但还需要一些不寻常的要求。

首先,这会在您的数据库和应用程序之间产生过多的流量。其次,在并发环境中,这将引入大量的竞争条件。

仅举一个简单的例子,代码段:

User.Items[3].ID = 13; 
User.Items[3].Color = Color.Blue; 

可能产生不允许的状态,但由于渴望持久化状态,它至少存在于数据库中一段时间​​。此外,上面的代码段将访问数据库两次,以便进行简单的更新。而且要保证这种变化是原子的要困难得多。

答案 1 :(得分:0)

您检查过LINQ to SQL还是实体框架?

它们都提供了与您需要的功能类似的功能:

// Get first user with Id of 5
var users = _dbContext.Users.FirstOrDefault(u => u.Id == 5);

// Loop through all users in the context
foreach(var user in _dbContext.Users)
{
    foreach(var item in user.Items)
    {
        // Work with your item here.
    }
}

您只需要确保管理上下文,以便获得最新信息。

答案 2 :(得分:0)

您需要在数据库类中实现IList,并在更改属性时写入数据库。

在某些情况下让IList访问数据可能会很好,但是当有人更改属性时自动写入数据库会在有人更改实例上的20个属性时产生令人不快的情况。

当谈到以类似集合的方式访问数据的最佳方式时,请查看LiNQ。

答案 3 :(得分:0)

您想要一个Object-Relational Mapping工具。

我使用并推荐ADO.Net Entity Framework

大多数ORM都包含缓存层。这就是你开始写的东西。

一个很大的好处是,您正在设计的缓存层是为您构建的,并且很可能会优于您(或我)的实现。

特别是对于Entity Framework,发挥作用的主要组件是“Object Services”组件

Entity Framework Component Stack http://upload.wikimedia.org/wikipedia/en/b/b7/ANEF.PNG

来自“Saving Changes and Managing Concurrency”......

  

对象服务跟踪更改   已被制作成对象   缓存。当SaveChanges方法是   调用,对象服务尝试合并   更改回数据源。   SaveChanges失败了   OptimisticConcurrencyException时   对象缓存中的数据更改   与所做的变化发生冲突   在对象之后的数据源中   在缓存中添加或刷新。

所以这主要是针对你的幕后操作。随着您的实体集的增长,您不必修改对象缓存层,因为它们都是为您完成的。

相关问题