MVVM on 寒流の编程笔记

如何在本地客户端使用 EF Core

Mon, 02 Feb 2026 00:00:00 +0000

Entity Framework Core (EF Core) 是一个强大的对象关系映射（ORM）框架，通常用于服务器端应用程序中与数据库交互。通常我们会将它用于 ASP.NET Core 应用程序，并且它的配置方式也绝对可以说是相当成熟了。但有时候我们在做本地客户端应用程序（例如 WPF、WinForms 或 Avalonia 应用程序）时，也希望利用 EF Core 来简化数据访问层的开发。那么我们需要注意些什么？最佳实践是怎样的？这篇文章我们就来探讨这个问题。

回顾 EF Core 在 ASP.NET Core 中的使用

首先我们来快速回顾一下在 ASP.NET Core 应用程序中使用 EF Core 的典型方式。以一个比较新（.NET 6+）的项目为例，通常我们会在程序入口进行如下的配置：

1
2
3
4
5
6
7
8


var builder = WebApplication.CreateBuilder(args);

// 配置 DbContext
builder.Services.AddDbContext<AppDbContext>(options =>
 options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

// 其他服务配置
// ...

这里其实有一个隐式的配置，就是我们将 DbContext 的生命周期设置为了作用域（Scoped）。在 ASP.NET Core 中，每个 HTTP 请求都会创建一个新的作用域，因此每个请求都会有一个独立的 DbContext 实例。这种方式有助于确保数据的一致性和隔离性。

这个方案在服务器端应用程序中可以说是非常标准且正确的，但是这个问题到了本地客户端，情况就不太相同了。对于客户端程序来说，通常并没有作用域这么一个概念。客户端程序一般是单用户的，整个应用程序的生命周期就是一个大的作用域。如果我们直接将 DbContext 注册为作用域生命周期，那么实际上它就会变成单例生命周期，这样就会带来一些问题：

线程安全问题：DbContext 不是线程安全的，如果在多线程环境下（例如 UI 线程和后台线程）共享同一个实例，可能会导致数据损坏或异常。
内存泄漏：长时间持有 DbContext 实例可能会导致内存泄漏，因为它会跟踪所有的实体状态，随着时间的推移，这些状态会不断累积。

因此，如何解决这两个问题就成了我们在客户端使用 EF Core 时需要重点考虑的内容。

方法一：注册为瞬态（Transient）生命周期

首先我们来看一种相对来说比较简单的方式。既然注册为作用域，实际上就相当于单例，那么我们可以直接将 DbContext 注册为瞬态生命周期。这样在每个被注入服务的类中，它都会获得一个新的 DbContext 实例，从而一定程度上避免了一些问题。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


// 注册 DbContext 服务
builder.Services.AddDbContext<AppDbContext>(options =>
 options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")),
 ServiceLifetime.Transient);

// 使用 DbContext 的服务
public class MyViewModel
{
 private readonly AppDbContext _dbContext;

 public MyViewModel(AppDbContext dbContext)
 {
 _dbContext = dbContext;
 }

 public void LoadData()
 {
 var items = _dbContext.Items.ToList();
 // 处理数据
 }
}

Info

对于一个客户端程序，尤其是 MVVM 模式，一个典型的情况是我们将 DbContext 注入到 ViewModel 中使用。当然对于更复杂的场景，我们可能会将数据访问逻辑封装到一个 Repository 或 Service 层中，然后再将这些服务注入到 ViewModel 中。至于没有使用 MVVM 模式的情形，我们基本上也不会搞 DI 容器，所以也就不考虑这些问题了。

那么这有没有问题呢？答案是有的，而且这个方案并不理想。比如我们看下面这个例子。在这个例子中，我们使用了 CommunityToolkit.Mvvm 来简化 ViewModel 的编写：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


public partial class MainViewModel : ViewModelBase
{
 private readonly AppDbContext _dbContext;

 [ObservableProperty]
 private ObservableCollection<Item> _loadedItems;

 public MainViewModel(AppDbContext dbContext)
 {
 _dbContext = dbContext;
 }
 
 [RelayCommand(AllowConcurrent = true)]
 private async Task LoadDataAsync()
 {
 var items = await _dbContext.Items.ToListAsync();
 LoadedItems = new(items);
 }
}

在这个例子中，我们将 DbContext 注入到了 MainViewModel 中，并且在 LoadDataAsync 方法中使用它来加载数据。这里其实就已经出现不少问题了：

MainViewModel 的实例通常生命周期非常长（可能与整个应用程序相同），而 DbContext 被注册为瞬态生命周期，这就意味着每次调用 LoadDataAsync 方法时，实际上都是在使用同一个 DbContext 实例。那这其实并没有比单例强多少，最多就是不用和其他服务共用同一个实例而已。长时间使用下去，DbContext 仍然会积累大量的状态，导致内存泄漏的问题。
这里我故意将 LoadDataAsync 方法设置为允许并发执行（AllowConcurrent = true）。这就意味着如果用户快速多次点击加载按钮，就会导致多个线程同时访问同一个 DbContext 实例，从而引发线程安全问题。

所以说，虽然将 DbContext 注册为瞬态生命周期在某些情况下可以工作，但它并不是一个理想的解决方案。除非我们能保证使用它的代码绝对不会并发执行，并且生命周期比较短（比如一个表单的视图模型），否则我们还是需要寻找更好的方法。

方法二：为服务注入作用域

既然上面的思路走不通，我们恐怕就不能简单地给视图模型直接注入 DbContext 了。为了解决上面的问题，我们应该让视图模型操作数据库的方法有机会每次都创建一个新的实例。顺着这个思路，我们可以让 DbContext 继续注册为作用域生命周期，然后为视图模型注入一个 IServiceScopeFactory，每次需要访问数据库时，就创建一个新的作用域，从而获得一个新的 DbContext 实例。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


public partial class MainViewModel : ViewModelBase
{
 private readonly IServiceScopeFactory _scopeFactory;

 [ObservableProperty]
 private ObservableCollection<Item> _loadedItems;

 public MainViewModel(IServiceScopeFactory scopeFactory)
 {
 _scopeFactory = scopeFactory;
 }
 
 [RelayCommand(AllowConcurrent = true)]
 private async Task LoadDataAsync()
 {
 using var scope = _scopeFactory.CreateScope();
 var dbContext = scope.ServiceProvider.GetRequiredService<AppDbContext>();
 
 var items = await dbContext.Items.ToListAsync();
 LoadedItems = new(items);
 }
}

Info

这里我们为 scope 使用了 using 语句，这样就可以确保在方法执行完成后，作用域会被正确地释放，从而避免内存泄漏的问题；另一方面，我们没有为 dbContext 使用 using 语句，因为它是由 scope 管理的，而后者会在 using 块结束时自动释放它所创建的所有服务实例。

方法三：使用 `IDbContextFactory`

或者我们还可以更简单一些，我们直接将 DbContext 注册为瞬态生命周期，然后为视图模型注入一个 IDbContextFactory<AppDbContext>，每次需要访问数据库时，就通过工厂创建一个新的 DbContext 实例。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


public partial class MainViewModel : ViewModelBase
{
 private readonly IDbContextFactory<AppDbContext> _dbContextFactory;

 [ObservableProperty]
 private ObservableCollection<Item> _loadedItems;

 public MainViewModel(IDbContextFactory<AppDbContext> dbContextFactory)
 {
 _dbContextFactory = dbContextFactory;
 }
 
 [RelayCommand(AllowConcurrent = true)]
 private async Task LoadDataAsync()
 {
 using var dbContext = _dbContextFactory.CreateDbContext();
 
 var items = await dbContext.Items.ToListAsync();
 LoadedItems = new(items);
 }
}

如果使用这种方式，我们还要稍微修改一下服务的注册。这次我们就不用 AddDbContext 了，而是使用 AddDbContextFactory 来注册 DbContext 工厂：

1
2
3


// 注册 DbContext 工厂
builder.Services.AddDbContextFactory<AppDbContext>(options =>
 options.UseSqlServer(connectionString));

Info

使用工厂方法创建一个 DbContext 的实例就类似于我们手动使用 new 关键字创建一个对象一样。每次调用 CreateDbContext 方法时，都会返回一个新的 DbContext 实例，这样就可以避免线程安全和内存泄漏的问题。但因此我们也要手动处理它的生命周期，确保在使用完成后正确地释放它。所以上面我们对它使用了 using 语句。

总结

总的来说，在本地客户端应用程序中使用 EF Core 时，我们需要特别注意 DbContext 的生命周期以及线程安全。只要解决了这两个问题，我们就可以放心地在客户端程序中使用 EF Core 来简化数据访问层的开发。

借助 ObservableCollections 获得更多具有通知功能的集合类型

Fri, 11 Jul 2025 00:00:00 +0000

如果大家在做基于 C# 的 WPF、Avalonia、Win UI 等开发，尤其是遵循 MVVM 模式时，遇到过下面的这些烦恼：

ObservableCollection 没有批量操作的功能（例如 AddRange）
缺少 ObservableDictionary、ObservableSet、ObservableQueue 等集合类型
难以实现诸如过滤、映射等功能

那么，ObservableCollections 这个 NuGet 包一定可以帮到你。没错，它就提供了一系列实用的具有通知功能的集合类型，使我们在 WPF、Avalonia、甚至 Unity 开发中都能够用得上。

安装

它的源代码链接在 GitHub 上。

如果想要安装它，我们只需要在 NuGet 包管理器中搜索 ObservableCollections，或者直接在项目中运行以下命令：

1

dotnet add package ObservableCollections

安装之后即可使用。注意它还有一个结尾包含 R3 的版本，是为它开发的 R3 库而准备的，通常我们不需要使用。这个 R3 库简单来说，就是一个更加高性能的 Rx.NET。

Info

说起它的开发者 Cysharp，那可真的可以说是如雷贯耳。比如他们开发的 Unitask，就是一个非常流行的适用于 Unity 的异步编程库；而他们开发的 ZLinq，最近也是非常有名。油管上的 Nick Chapsas 也曾经介绍过这个库。

支持批量操作的可观测集合

我们先来看一看它最简单的 ObservableList。它是一个具有通知功能的列表，并且支持批量操作。我们只需要实例化，然后就可以使用它了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


class MainViewModel
{
 private readonly ObservableList<string> _items = new();

 public MainViewModel()
 {
 // 添加单个元素
 _items.Add("Item 1");
 
 // 批量添加元素
 _items.AddRange(GetItems());
 }

 private IEnumerable<string> GetItems()
 {
 // 假定这个方法可以从某个数据源获取一些数据
 }
}

通过观察可以发现，这个集合类型提供了 CollectionChanged 事件，我们可以通过订阅它来监听集合的变化。但是先不要想当然地认为它和 ObservableCollection 一样。实际上，它的 CollectionChanged 事件并不是来自我们熟悉的那个 INotifyCollectionChanged 接口，而是这个库自带的一个接口。所以我们在上面的代码中，并没有直接将这个集合声明为 public 的属性，从而在 XAML 中绑定。

那么它为什么要这样做，让我们不能方便地使用呢？其实原因很简单：这个库不单单适用于 WPF，它还可以用于 Avalonia、Unity 等框架。为了兼容更多的框架，它就没有使用 INotifyCollectionChanged 接口，而是提供了一个更通用的接口。

但不必担心，它并没有止步于此，而是专门提供了方便我们在 WPF、Avalonia 等框架中使用的额外类型。简单来说，我们只需要调用它的下面这个方法，即可将它转为可以用于 XAML 绑定的集合对象：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


class MainViewModel
{
 private readonly ObservableList<string> _items = new();

 public INotifyCollectionChangedSynchronizedViewList<string> Items { get; }

 public MainViewModel()
 {
 Items = _items.ToNotifyCollectionChanged();
 }
}

这里的 INotifyCollectionChangedSynchronizedViewList 就继承了 INotifyCollectionChanged 接口，因此实现了该接口的对象就可以直接在 XAML 中绑定使用，例如：

1

<ListBox ItemsSource="{Binding Items}" />

接下来，我们只需要在后台操作 _items 集合，它的变化即可同步到 Items 集合中，从而在 UI 上自动更新。

创建集合视图

实际上，对于 ObservableList，我们除了可以使用 ToNotifyCollectionChanged 方法将其转换为可以用于 XAML 绑定的集合类型外，还可以使用 ToNotifyCollectionChangedSlim 方法，将它转为一个更加轻量级的集合类型。这个类型同样实现了 INotifyCollectionChanged 接口，但它的性能更高，适用于需要频繁更新的场景。代价是，它将不提供 AddRange 等批量操作方法。

这时候可能有同学就会问了：我用 ObservableList 而不是原生的 ObservableCollection，不就是为了它提供的批量操作方法吗？如果我不需要批量操作，直接用 ObservableCollection 不就行了吗？

这就引出了我们即将介绍的下一个功能，同时也是这个库相当重要的功能：View。这个 View 不是我们常说的 MVVM 中的视图，而是指对集合的视图。它可以让我们在不改变原始集合的情况下，对集合进行过滤、映射等操作。我们不需要关注视图的实现细节，只需要操作后台的集合，即可将更改同步到界面中。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


class MainViewModel
{
 private readonly ObservableList<string> _items = new();

 private readonly ISynchronizedView<string, string> _syncView;

 public INotifyCollectionChangedSynchronizedViewList<string> Items { get; }

 public MainViewModel()
 {
 _syncView = _items.CreateView(s => s.ToUpper());
 Items = _syncView.ToNotifyCollectionChanged();
 }

 public void ToggleFilter(bool useFilter)
 {
 if (useFilter)
 {
 _syncView.AttachFilter(s => s.StartsWith("A")); // 过滤以 "A" 开头的元素
 }
 else
 {
 _syncView.ResetFilter(); // 清除过滤器
 }
 }
}

Tip

如果我们只是想使用映射功能，那么使用 ToNotifyCollectionChanged 方法即可。它有一个重载，可以传入一个表示映射方式的 Func。另外，它还支持传入一个类似 Dispatcher 的参数，用于在 UI 线程上执行映射操作。至于为什么不是 WPF 中的 Dispatcher，而是一个它自己声明的类型，这也是为了兼容更多的框架。

在上面的代码中，我们创建了一个视图 _syncView。在创建时，我们就指定了一个映射函数，将集合中的每个元素转换为大写形式。然后在 ToggleFilter 方法中，我们可以通过 AttachFilter 及 ResetFilter 方法来添加或移除过滤器。就这样，我们轻松地实现了对集合的过滤和映射功能。

简单想象一下，这些功能在 WPF、Avalonia 等框架中原本实现起来会多么麻烦。对于映射，我们可以借助 DataTemplate 以及 ValueConverter 来实现；而对于过滤，我们可能需要使用 CollectionView 或者 ICollectionView 等。这些都需要我们编写大量的样板代码。

可观测的字典

WPF 中其实有一个 ObservableDictionary，但它并不是 public 的，只是标准库内部使用。或许我们可以使用一个 ObservableCollection<KeyValuePair<TKey, TValue>> 来模拟一个字典，但这效率并不高，因为字典的添加、删除、查找等操作都是 $O(1)$ 的，而 ObservableCollection 的这些操作都是 $O(n)$ 的。

至于 Avalonia，我们就比较幸运了，它直接提供了 AvaloniaList 和 AvaloniaDictionary，这两个集合类型，前者支持批量操作，后者则是一个可观测的字典。

下面我们用一个简单的例子来演示如何使用这个 ObservableDictionary。它的使用方式和 ObservableList 类似，我们只需要实例化它，然后就可以使用了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


class MainViewModel
{
 private readonly ObservableDictionary<string, string> _items = new();

 public INotifyCollectionChangedSynchronizedViewList<string> Items { get; }

 public MainViewModel()
 {
 Items = _items.ToNotifyCollectionChanged(pair => pair.Value);

 _items.Add("Key1", "Value1");
 }
}

可观测的队列

队列有时候也是一个我们用得上的集合类型。它的特点是先进先出（FIFO），适用于需要按照顺序处理元素的场景。比如我们希望存储一些实时的消息，并且希望仅展示最新的几十条，而当超过这个数量时，自动删除最旧的消息。这就要求我们需要能够高效地删除队列头部的元素。这对于传统的列表来说是比较麻烦的，因为这会引入 $O(n)$ 的时间复杂度。

ObservableCollections 库提供了一个 ObservableQueue<T>，不过我不打算详细介绍它，因为我们上面提到的需求有一个更加合适的集合类型，等下就会介绍到。但这里我们还是用一个简单的例子来演示它的用法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


class MainViewModel
{
 private readonly ObservableQueue<LogMessage> _logQueue = new();

 public INotifyCollectionChangedSynchronizedViewList<LogMessage> LogMessages { get; }

 public MainViewModel()
 {
 LogMessages = _logQueue.ToNotifyCollectionChanged();

 // 添加日志消息
 AddLogMessage("Application started");
 }

 public void AddLogMessage(string content)
 {
 var logMessage = new LogMessage(DateTime.Now.ToString("o"), content);

 // 如果队列超过 100 条，则删除最旧的消息
 if (_logQueue.Count >= 100)
 {
 _logQueue.Dequeue();
 }
 _logQueue.Enqueue(logMessage); 
 }
}

record LogMessage(string Timestamp, string Content);

Tip

事实上，如果我们的需求只是比如说保留最近的几十到一百条消息，那么直接使用传统的 ObservableCollection 也是完全可以接受的。虽然有点性能损失，但对于现在的 CPU 来说，这点复杂度完全是微不足道的。通过简单的 Benchmark，我们可以看到，List 可能只比 Queue 慢 50% 左右；甚至当数据量比较小（例如十几条）时，List 更是能在性能上超过 Queue。另外，List 的使用显然比 Queue 简单了不少。

可观测的环形缓冲区

下面我们要介绍的这个集合类型，正是这个包最推荐我们用来实现这个保留最近的一些消息的集合类型：RingBuffer。它是一个环形缓冲区，具有固定的大小。当添加新元素时，如果缓冲区已满，则会覆盖最旧的元素。这使得它非常适合用于存储最近的消息或数据。

这个包提供了两种环形缓冲区：ObservableRingBuffer 和 ObservableFixedSizeRingBuffer。前者支持动态调整大小，而后者则是一个固定大小的环形缓冲区。借助后者，我们前面的例子可以简化为：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


class MainViewModel
{
 private readonly ObservableFixedSizeRingBuffer<LogMessage> _logBuffer = new(100);

 public INotifyCollectionChangedSynchronizedViewList<LogMessage> LogMessages { get; }

 public MainViewModel()
 {
 LogMessages = _logBuffer.ToNotifyCollectionChanged();

 // 添加日志消息
 AddLogMessage("Application started");
 }

 public void AddLogMessage(string content)
 {
 var logMessage = new LogMessage(DateTime.Now.ToString("o"), content);
 _logBuffer.Add(logMessage); // 添加新消息，自动覆盖最旧的消息
 }
}

就这样，我们轻松地实现了一个保留最近 100 条日志消息的集合。

线程安全

接下来这个部分相当重要，也是大家在使用这个包时需要尤其注意的，就是关于线程安全的问题。首先，这个包提供的每个集合都是线程安全的。它们内部会用一个线程锁，保证它的添加、删除等操作是线程安全的。但这并不意味着我们就可以高枕无忧了，因为虽然这些集合线程安全，但是从它们创建出的视图在同步它们的修改时，可能出现线程安全问题。那么，我们该怎么办呢？

首先，在使用 ToNotifyCollectionChanged 方法时，我们可以传入一个 Dispatcher 参数。前面提到，这个参数是该类库自己声明的类型。但是它提供了一个方便我们使用的单例：SynchronizationContextCollectionEventDispatcher.Current。借助它，我们就可以确保该方法创建出的视图在 UI 线程上执行修改操作，从而避免线程安全问题。

但是这还不够。实测发现，虽然背后的集合本身线程安全，但是它创建出来的视图在操作时仍面临着线程安全问题。尤其是数据不一致。比如我们在删除元素之后立刻添加了元素，那么这两次动作在同步到视图的过程中就可能会出现问题。对于这个问题，如果我们确实有在多线程上操作背后集合的需求，那么我们可以考虑让这些操作都发生在主线程上。以 WPF 为例，我们可以这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


class MainViewModel
{
 private readonly ObservableList<string> _items = new();

 public INotifyCollectionChangedSynchronizedViewList<string> Items { get; }

 public MainViewModel()
 {
 Items = _items.ToNotifyCollectionChanged(SynchronizationContextCollectionEventDispatcher.Current);
 }

 public void AddItem(string item)
 {
 // 确保在 UI 线程上执行添加操作
 Application.Current.Dispatcher.InvokeAsync(() => _items.Add(item));
 }

 public void RemoveItem(string item)
 {
 // 确保在 UI 线程上执行删除操作
 Application.Current.Dispatcher.InvokeAsync(() => _items.Remove(item));
 }
}

当然，在 ViewModel 中访问 Application.Current 可能并不是一个十分遵守 MVVM 模式的好习惯。因此在更加严谨的项目中，我们可以考虑将 Dispatcher 作为参数传入 ViewModel，或者使用依赖注入的方式来获取它。这样可以更好地遵循 MVVM 模式，同时也能确保在 UI 线程上执行操作。

总结

ObservableCollections 是一个非常实用的 NuGet 包，它提供了多种具有通知功能的集合类型，适用于 WPF、Avalonia、Win UI 等框架。它不仅支持批量操作，还提供了过滤、映射等功能，使得我们在开发中可以更加高效地处理集合数据。

在使用时，我们需要注意线程安全问题，尤其是在多线程环境下操作集合时。通过合理地使用 Dispatcher，我们可以确保集合的操作在 UI 线程上执行，从而避免数据不一致的问题。

如何在 WPF 中实现符合 MVVM 模式的文件拖入功能

Wed, 08 May 2024 00:00:00 +0000

本篇文章对应的教学视频链接：WPF中如何实现符合MVVM模式的文件拖入功能

原始方式

在 WPF 中，实现文件拖入功能并不难。稍微在网上搜索一下，就能够得到答案。比如现在有一个窗口，我们只需要设置它的 AllowDrop 属性为 True，然后在 Drop 事件中处理即可。形如：

1
2
3


<Window ...
 AllowDrop="True"
 Drop="Window_Drop">

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


public partial class MainWindow : Window
{
 public MainWindow()
 {
 InitializeComponent();
 }

 private void Window_Drop(object sender, DragEventArgs e)
 {
 if (e.Data.GetDataPresent(DataFormats.FileDrop))
 {
 var files = (string[])e.Data.GetData(DataFormats.FileDrop);
 // 处理拖入的文件
 }
 }
}

添加视图模型

但问题是，如果现在 Window 拥有一个视图模型（ViewModel），形如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


public class MainViewModel : ViewModelBase
{
 private string? _fileName;
 public string? FileName
 {
 get => _fileName;
 set
 {
 _fileName = value;
 OnPropertyChanged(this, nameof(FileName));
 }
 }
}

Info

这里我们假定已经实现了 ViewModelBase 类，它实现了 INotifyPropertyChanged 接口，并提供了 OnPropertyChanged 方法以便于通知属性发生了变化。

然后 Window 上面有一个 TextBox 绑定了这个属性，这又该怎么办呢？

这里有两种比较简单粗暴的方式：

为 TextBox 添加一个 Name，然后在 Window 的 Drop 事件中直接修改 TextBox 的 Text 属性，进而使用依赖属性的一些方法来通知绑定的 ViewModel 属性发生了变化
在 Window 的 Drop 事件中直接修改 ViewModel 的属性（获取 Window.DataContext，并将其转为 MainViewModel 类型），然后在 ViewModel 中实现 INotifyPropertyChanged 接口，进而通知 TextBox 的 Text 属性发生了变化

这两种方式都很直接，而且其实都不违背 MVVM 模式。但是这两种方式并不优雅，所以这里我们借助行为（Behaviors）来实现一个更加优雅且通用的方式。

使用行为

首先，我们需要安装 Microsoft.Xaml.Behaviors.Wpf 包。然后我们可以创建一个 DropFileBehavior 类，形如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


public class DropFileBehavior : Behavior<FrameworkElement>
{
 public string[]? Data
 {
 get => (string[]?)GetValue(FilesProperty);
 set => SetValue(FilesProperty, value);
 }

 public static readonly DependencyProperty FilesProperty = DependencyProperty.Register(
 nameof(Data),
 typeof(string[]),
 typeof(DropFileBehavior),
 new UIPropertyMetadata(null)
 );

 protected override void OnAttached()
 {
 AssociatedObject.AllowDrop = true;
 AssociatedObject.Drop += DropHandler;
 }

 protected override void OnDetaching()
 {
 AssociatedObject.Drop -= DropHandler;
 }

 private void DropHandler(object sender, DragEventArgs e)
 {
 if (e.Data.GetDataPresent(DataFormats.FileDrop))
 {
 Data = (string[])e.Data.GetData(DataFormats.FileDrop);
 }
 }
}

这个行为大致实现的功能是：

当附加到一个 FrameworkElement 上时，将其 AllowDrop 属性设置为 True，并注册 Drop 事件
当拖入文件时，将文件路径保存到 Data 依赖属性中

然后我们就可以在 XAML 中使用这个行为了（因为这里我们声明的 Data 属性是一个数组，所以我们稍微修改 MainViewModel 中相关属性的名称及类型，从而实现绑定功能）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


<Window ...
 xmlns:i="http://schemas.microsoft.com/xaml/behaviors"
 xmlns:local="clr-namespace:YourNamespace">

 <i:Interaction.Behaviors>
 <local:DropFileBehavior Data="{Binding FileNames, Mode=OneWayToSource}" />
 </i:Interaction.Behaviors>

 <TextBox Text="{Binding FileNames[0]}" />
</Window>

注意这里，我们在书写行为的 Data 属性的绑定时，使用了 Mode=OneWayToSource，这是因为我们只需要将数据从视图传递到视图模型，而不需要反向传递。并且如果不写 Mode，它默认将会是 OneWay，导致可能无法正确通知到 ViewModel。

制作界面

最后，我们还可以搞一个“酷炫”的界面，形如：

首先，我们可以在窗口中添加这样一个置于上方的控件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


<Grid Name="dropFilePanel" Visibility="Hidden">
 <Border Background="White" Opacity="0.8" />
 <TextBlock HorizontalAlignment="Center"
 VerticalAlignment="Center"
 Text="将文件拖放到此处" />
 <Rectangle Width="200"
 Height="100"
 Stroke="Gray"
 RadiusX="10"
 RadiusY="10"
 StrokeDashArray="3,4"
 StrokeThickness="2" />
</Grid>

同时，因为我们现在有了这个专门的用于放置文件的面板，所以我们可以将之前添加给窗口的行为转移到它身上，形如：

1
2
3
4
5


<Grid Name="dropFilePanel" Visibility="Hidden">
 <i:Interaction.Behaviors>
 <local:DropFileBehavior Data="{Binding FileNames, Mode=OneWayToSource}" />
 </i:Interaction.Behaviors>
 ...

但是我们要控制它在合适的时机出现与消失。这里我们可以使用触发器与行为来快速地实现这一效果。具体来说，我们可以给窗口添加这样的触发器：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


<Window ...
 xmlns:b="http://schemas.microsoft.com/xaml/behaviors">
 <b:Interaction.Triggers>
 <b:EventTrigger EventName="DragEnter">
 <b:ChangePropertyAction TargetObject="{Binding ElementName=dropFilePanel}" PropertyName="Visibility" Value="Visible" />
 </b:EventTrigger>
 <b:EventTrigger EventName="DragLeave">
 <b:ChangePropertyAction TargetObject="{Binding ElementName=dropFilePanel}" PropertyName="Visibility" Value="Hidden" />
 </b:EventTrigger>
 </b:Interaction.Triggers>
 ...

这样，当鼠标拖入窗口时，dropFilePanel 就会显示出来；当鼠标拖出窗口时，dropFilePanel 就会被隐藏。

实际测试后会发现，当我们将文件拖到上方并松开左键后，虽然行为得到了正确的响应，但面板并没有消失。这是因为我们上面写的触发器只会在鼠标拖动状态离开窗口后才会隐藏面板。所以这里，我们可以再为面板添加一个触发器，并在它触发了 Drop 事件后将自身隐藏：

1
2
3
4
5
6


<Grid Name="dropFilePanel" Visibility="Hidden">
 <b:Interaction.Triggers>
 <b:EventTrigger EventName="Drop">
 <b:ChangePropertyAction PropertyName="Visibility" Value="Hidden" />
 </b:EventTrigger>
 </b:Interaction.Triggers>

这样，上面动图中的效果就实现了。

总结

WPF 开发必然会经常和控件的事件打交道。但很多时候，如果我们希望遵循 MVVM 模式，可能就会不知所措。相信大家通过这篇文章的代码，都能够充分领略到使用触发器与行为的强大之处。当然，这里只是一个简单的例子，实际开发中，我们还可以为上面的例子添加更多丰富的功能及特效。这些就有待大家的探索了。

大家如果有什么自己的好方法，也欢迎在文章评论区留言，分享给大家。

MVVM on 寒流の编程笔记

如何在本地客户端使用 EF Core

回顾 EF Core 在 ASP.NET Core 中的使用

方法一：注册为瞬态（Transient）生命周期

方法二：为服务注入作用域

方法三：使用 IDbContextFactory

总结

借助 ObservableCollections 获得更多具有通知功能的集合类型

安装

支持批量操作的可观测集合

创建集合视图

可观测的字典

可观测的队列

可观测的环形缓冲区

线程安全

总结

如何在 WPF 中实现符合 MVVM 模式的文件拖入功能

原始方式

添加视图模型

使用行为

制作界面

总结

方法三：使用 `IDbContextFactory`