如何...显示数据库中的数据

时间:2022-01-13 18:41:11

I've got an Application which consists of 2 parts at the moment

我有一个应用程序,目前由两部分组成

  1. A Viewer that receives data from a database using EF
  2. 使用EF从数据库接收数据的查看器

  3. A Service that manipulates data from the database at runtime.
  4. 在运行时从数据库处理数据的服务。

The logic behind the scenes includes some projects such as repositories - data access is realized with a unit of work. The Viewer itself is a WPF-Form with an underlying ViewModel.

幕后的逻辑包括一些项目,如存储库 - 数据访问是通过一个工作单元实现的。 Viewer本身是一个带有底层ViewModel的WPF表单。

The ViewModel contains an ObservableCollection which is the datasource of my Viewer.

ViewModel包含一个ObservableCollection,它是我的Viewer的数据源。

Now the question is - How am I able to retrieve the database-data every few minutes? I'm aware of the following two problems:

现在的问题是 - 我怎么能每隔几分钟检索一次数据库数据?我知道以下两个问题:

  1. It's not the latest data my Repository is "loading" - does EF "smart" stuff and retrieves data from the local cache? If so, how can I force EF to load the data from the database?
  2. 这不是我的存储库“加载”的最新数据 - EF“智能”的东西并从本地缓存中检索数据?如果是这样,我如何强制EF从数据库加载数据?

  3. Re-Setting the whole ObservableCollection or adding / removing entities from another thread / backgroundworker (with invokation) is not possible. How am I supposed to solve this?
  4. 无法重新设置整个ObservableCollection或从另一个线程/后台工作者(使用invokation)添加/删除实体。我该怎么解决这个问题?

I will add some of my code if needed but at the moment I don't think that this would help at all.

如果需要,我会添加一些代码,但目前我认为这根本不会有所帮助。

Edit:

public IEnumerable<Request> GetAllUnResolvedRequests() {
        return AccessContext.Requests.Where(o => !o.IsResolved);
    }

This piece of code won't get the latest data - I edit some rows manually (set IsResolved to true) but this method retrieves it nevertheless.

这段代码将无法获取最新数据 - 我手动编辑了一些行(将IsResolved设置为true),但此方法仍会检索它。

Edit2:

如何...显示数据库中的数据

如何...显示数据库中的数据

Edit3:

var requests = AccessContext.Requests.Where(o => o.Date >= fromDate && o.Date <= toDate).ToList();
        foreach (var request in requests) {
            AccessContext.Entry(request).Reload();
        }
        return requests;

Final Question: The code above "solves" the problem - but in my opinion it's not clean. Is there another way?

最后的问题:上面的代码“解决”了问题 - 但在我看来它并不干净。还有另一种方式吗?

2 个解决方案

#1


1  

When you access an entity on a database, the entity is cached (and tracked to track changes that your application does until you specify AsNoTracking).
This has some issues (for example, performance issues because the cache increases or you see an old version of entities that is your case).
For this reasons, when using EF you should work with Unit of work pattern (i.e. you should create a new context for every unit of work).

当您访问数据库上的实体时,实体将被缓存(并跟踪以跟踪应用程序执行的更改,直到您指定AsNoTracking)。这有一些问题(例如,性能问题,因为缓存增加或您看到旧版本的实体是您的情况)。出于这个原因,当使用EF时,您应该使用工作单元模式(即,您应该为每个工作单元创建一个新的上下文)。

You can have a look to this Microsoft article to understand how implement Unit of work pattern. http://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

您可以查看这篇Microsoft文章,了解如何实现工作单元模式。 http://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-在安-ASP净MVC应用程序

In your case using Reload is not a good choice because the application is not scalable. For every reload you are doing a query to database. If you just need to return desired entities the best way is to create a new context.

在您的情况下,使用Reload不是一个好选择,因为应用程序不可扩展。对于每次重新加载,您都在对数据库进行查询。如果您只需要返回所需的实体,最好的方法是创建一个新的上下文。

public IEnumerable<Request> GetAllUnResolvedRequests() 
{
    return GetNewContext().Requests.Where(o => !o.IsResolved).ToList();
}

#2


0  

Here is what you can do.

这是你可以做的。

You can define the Task (which keeps running on ThreadPool) that periodically checks the Database (consider that periodically making EF to reload data has its own cost).

您可以定义定期检查数据库的Task(它继续在ThreadPool上运行)(考虑定期使EF重新加载数据有其自己的成本)。

And You can define SQL Dependency on your query so that when there is a change in data, you can notify the main thread for the same.

您可以在查询中定义SQL依赖关系,以便在数据发生更改时,您可以通知主线程。

#1


1  

When you access an entity on a database, the entity is cached (and tracked to track changes that your application does until you specify AsNoTracking).
This has some issues (for example, performance issues because the cache increases or you see an old version of entities that is your case).
For this reasons, when using EF you should work with Unit of work pattern (i.e. you should create a new context for every unit of work).

当您访问数据库上的实体时,实体将被缓存(并跟踪以跟踪应用程序执行的更改,直到您指定AsNoTracking)。这有一些问题(例如,性能问题,因为缓存增加或您看到旧版本的实体是您的情况)。出于这个原因,当使用EF时,您应该使用工作单元模式(即,您应该为每个工作单元创建一个新的上下文)。

You can have a look to this Microsoft article to understand how implement Unit of work pattern. http://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

您可以查看这篇Microsoft文章,了解如何实现工作单元模式。 http://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-在安-ASP净MVC应用程序

In your case using Reload is not a good choice because the application is not scalable. For every reload you are doing a query to database. If you just need to return desired entities the best way is to create a new context.

在您的情况下,使用Reload不是一个好选择,因为应用程序不可扩展。对于每次重新加载,您都在对数据库进行查询。如果您只需要返回所需的实体,最好的方法是创建一个新的上下文。

public IEnumerable<Request> GetAllUnResolvedRequests() 
{
    return GetNewContext().Requests.Where(o => !o.IsResolved).ToList();
}

#2


0  

Here is what you can do.

这是你可以做的。

You can define the Task (which keeps running on ThreadPool) that periodically checks the Database (consider that periodically making EF to reload data has its own cost).

您可以定义定期检查数据库的Task(它继续在ThreadPool上运行)(考虑定期使EF重新加载数据有其自己的成本)。

And You can define SQL Dependency on your query so that when there is a change in data, you can notify the main thread for the same.

您可以在查询中定义SQL依赖关系,以便在数据发生更改时,您可以通知主线程。