我应该何时更新数据库以反映属性更改?

发布于 2025-01-07 09:48:14 字数 416 浏览 1 评论 0原文

我是 WPF 新手,正在使用 Linq To Entities(和 SQLite 数据库)构建一个小型应用程序。

我只是想知道,当属性发生更改时,我必须在哪里调用我的方法才能更新数据库? 我会在 ViewModel 的属性中这样说:

public string FirstName
{
    get
    {
        return this.person.FirstName;
    }
    set
    {
        this.person.FirstName = value;
        OnPropertyChanged("FirstName");
        this.person.updateFirstname(value);
    }
}

我不确定这是否是最好的解决方案......

I am new to WPF and I am building a small app with Linq To Entities (and SQLite database).

I just would like to know, where do I have to call my methods in order to update the database, when a property has changed ?
I would say in the property in ViewModel like this :

public string FirstName
{
    get
    {
        return this.person.FirstName;
    }
    set
    {
        this.person.FirstName = value;
        OnPropertyChanged("FirstName");
        this.person.updateFirstname(value);
    }
}

I am not sure if this is the best solution...

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

深者入戏 2025-01-14 09:48:15

何时保存到数据库的问题引发了工作单元模式。 Linq-to-Entities 通过 对此进行了合理的实现ObjectContext,数据在上下文中排队,然后在逻辑工作单元完成时保存到数据库。

在您的示例中,您已经在 L2E 实体 Person 上设置属性,该实体可能已连接到上下文。当您调用ObjectContext.SaveChanges时,这将被保存,无需updateFirstname 方法。

您必须决定何时调用 ObjectContext.SaveChanges (从而结束工作单元),并在用户显式保存或关闭表单时执行此操作(可以选择提示用户提交或放弃更改)是一种合理的方法。为了实现这一点,您的视图模型引用 ObjectContext,并且可以在用户操作(通常使用 WPF ICommand 建模)由 viewmodel 发布并绑定到view) 被执行。

The problem of when to save to the database gives rise to the Unit of Work pattern. Linq-to-Entities has a reasonable implementation of this with the ObjectContext, where data is queued up in the context and then saved to the database when the logical unit of work is complete.

In your example, you are already setting the property on the L2E entity, Person, which is likely connected to the context. When you call ObjectContext.SaveChanges, this will be saved without the need for the updateFirstname method.

The thing you have to decide is when to call ObjectContext.SaveChanges (and thus end the unit of work), and doing this when the user explicitly saves or when the form is closed (optionally propmting for the user to commit or discard changes) is a reasonable approach here. To implement this, your viewmodels reference the ObjectContext and can call the SaveChanges method when the user action (usually modeled with a WPF ICommand published by the viewmodel and bound to the view) is executed.

烟沫凡尘 2025-01-14 09:48:15

您应该将更新集中在工作单元而不是单个字段上。如果您的数据库被正确规范化,每一行将代表一个实体,并且应该被如此对待,对实体的更新应该使实体保持在“有效”状态。在您的场景中,如果您更新某人的名字并打算同时更新姓氏,如果应用程序或服务器炸毁您的个人记录,则该记录将无效。

就 MVVM 而言,我通常要么搭载网格的“一次更新整行”策略并将该事件路由到视图模型中,要么只是给它们一个保存按钮:)

You should concentrate your updates around unit-of-work rather than around individual fields. If your database is properly normalized each row will represent an entity and should be treated as such, updates to an entity should keep an entity in "valid" state. In your scenario if you update person's first name with intention of also updating last name if the app or server blows up your person record will be invalid.

In terms of MVVM, I usually either piggyback on grid's "update entire row at once" strategy and route that event into viewmodel or I just give them a save button :)

安静 2025-01-14 09:48:15

最好将服务接口注入到 ViewModel 构造函数中,并使用某种类型的服务来更新数据库。
这样你最终会得到松散耦合的系统,并且你的 ViewModel 与你的数据访问层保持不可知,因为它应该......

It is best to inject a service Interface into your ViewModel constructor and use some type of service to update the database.
This way you end up with loosely coupled system and your ViewModel stays agnostic of your Data Access Layer as it should...

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文