VM中实例化类是否符合MVVM规范？XAML绑定问题咨询

Great question—let’s break this down clearly, since MVVM can feel tricky when you’re working out the details!

Short answer: No, directly instantiating concrete classes in your ViewModel usually breaks MVVM principles. Here’s why:
MVVM is all about separation of concerns and testability. When you new up a class (like a data service or repository) inside your VM, you’re creating tight coupling between the VM and that specific implementation. This makes it impossible to swap out the class for a mock during unit testing (say, you don’t want to hit a real database in tests), and it violates the Dependency Inversion Principle—your VM should depend on abstractions, not concrete types.

The right approach: Dependency Injection (DI) #

The cleanest way to handle dependencies is to inject them into your ViewModel, typically via constructor injection. Here’s how it works:

• First, define an abstract interface for your dependency (e.g., a data service):

  public interface IDataService
  {
      Task<List<MyData>> FetchDataAsync();
  }
  

• Create a concrete implementation of that interface:

  public class RealDataService : IDataService
  {
      public async Task<List<MyData>> FetchDataAsync()
      {
          // Actual logic to fetch data (API, database, etc.)
      }
  }
  

• Inject the interface into your ViewModel’s constructor:

  public class MainViewModel : BindableBase
  {
      private readonly IDataService _dataService;
  
      // Dependency is injected here
      public MainViewModel(IDataService dataService)
      {
          _dataService = dataService;
      }
  
      // Use the injected dependency in your methods
      public async Task LoadData()
      {
          var data = await _dataService.FetchDataAsync();
          // Update your bindable properties here
      }
  }
  

• Finally, register the interface and its implementation with a DI container (Xamarin.Forms has a built-in DependencyService, or you can use third-party tools like Prism, Autofac, or Microsoft’s DI). This way, the framework handles creating and injecting the dependency for you.

Looking at your truncated XAML, you’ve already set the BindingContext of MainPage to MainViewModel—good start! Now, to bind your ContentView’s Content property to the VM, here are key things to check:

First, ensure your ViewModel has a bindable property #

Your VM needs to expose a property that the ContentView can bind to, and it must implement INotifyPropertyChanged (most MVVM frameworks include a base class like BindableBase to handle this):

public class MainViewModel : BindableBase
{
    private View _contentViewContent;
    public View ContentViewContent
    {
        get => _contentViewContent;
        set => SetProperty(ref _contentViewContent, value);
    }

    // Alternatively, if you're binding a ViewModel for the ContentView:
    private object _contentSubViewModel;
    public object ContentSubViewModel
    {
        get => _contentSubViewModel;
        set => SetProperty(ref _contentSubViewModel, value);
    }
}

Correct your XAML binding #

If you’re binding the ContentView’s Content directly to the VM’s property:

<ContentPage x:Class="MvvM.Views.MainPage"
             xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:local="clr-namespace:MvvM.Views"
             xmlns:vm="clr-namespace:MvvM.ViewModels">
    <ContentPage.BindingContext>
        <vm:MainViewModel />
    </ContentPage.BindingContext>

    <!-- Bind the ContentView's Content to your VM property -->
    <local:YourCustomContentView Content="{Binding ContentViewContent}" />
</ContentPage>

A more common (and cleaner) pattern is to assign the ContentView its own BindingContext (if it has its own ViewModel):

<local:YourCustomContentView BindingContext="{Binding ContentSubViewModel}" />

Then, inside YourCustomContentView.xaml, you can bind directly to properties on ContentSubViewModel without worrying about the parent context.

Note about inherited BindingContext #

By default, the ContentView will inherit the BindingContext of its parent ContentPage. So if your ContentView’s internal controls need to bind to properties on MainViewModel, you don’t need to set a separate BindingContext—they’ll automatically use the parent’s context.

内容的提问来源于stack exchange，提问作者Jungle_Jon