.NET MAUI不使用Shell时，两种页面构造方式的差异与弊端

我正在开发一款不使用Shell的.NET MAUI移动应用，在实现页面与ViewModel的数据绑定上遇到了疑问，以下是相关场景和两种实现方式的对比：

基础配置回顾 #

Shell导航的页面配置 #

使用Shell时，只需在AppShell.xaml中配置页面路由即可实现跳转：

<ShellContent
        Title="Home"
        ContentTemplate="{DataTemplate local:MainPage}"
        Route="MainPage" />

非Shell的基础页面设置 #

不使用Shell时，需在App.xaml.cs中直接设置主页面：

public App(){
     MainPage = new MainPage();
     // 也可使用导航页包裹实现页面栈管理
     MainPage = new NavigationPage(new MainPage());
}

ViewModel绑定的基础要求 #

当通过MainPageViewModel实现数据绑定时，页面构造函数需要接收ViewModel实例并设置BindingContext：

public partial class MainPage : Flyout
{
    public MainPage(MainPageViewModel viewModel){
       InitializeComponent();
       BindingContext = viewModel;
    }
}

两种实现方式 #

方式1：在App.xaml.cs中传入ViewModel实例 #

直接在App的构造函数中手动创建ViewModel并传入页面：

public App(){
     MainPage = new MainPage(new ViewModels.MainPageViewModel());

     // 若ViewModel依赖其他服务（如DatabaseContext），代码会变得冗长
     MainPage = new MainPage(new ViewModels.MainPageViewModel(new DatabaseContext()));
}

方式2：在MainPage的无参构造函数中实例化ViewModel #

页面自主创建ViewModel，App只需直接实例化页面：
App.xaml.cs：

public App(){
     MainPage = new MainPage();
}

MainPage.xaml.cs：

public MainPage(){
   InitializeComponent();
   BindingContext = new MainPageViewModel();
}

本质差异与各自弊端 #

本质差异 #

• 方式1属于手动控制反转：ViewModel的创建权交给上层（App类），页面仅作为ViewModel的使用者，符合控制反转（IoC）思想。
• 方式2是强耦合实现：页面直接负责ViewModel的实例化，页面与ViewModel绑定紧密，ViewModel的创建逻辑被硬编码在页面内部。

方式1的弊端 #

• 依赖层级加深时，手动实例化会产生嵌套冗长的代码，比如ViewModel依赖Repository、Repository依赖数据库上下文，每次实例化都要逐层创建，维护成本高。
• 无法灵活替换ViewModel实现，比如测试时想用Mock ViewModel替代真实实现，必须修改App的代码，违反开闭原则。
• 没有利用.NET MAUI内置的依赖注入容器，无法享受DI带来的生命周期管理、自动注入等便利，后续扩展复杂依赖时会更麻烦。

方式2的弊端 #

• 页面与ViewModel强耦合，无法独立测试页面：测试页面UI逻辑时，必须连带实例化真实的ViewModel及其所有依赖，无法使用Mock对象隔离测试。
• 扩展性差，一旦ViewModel需要新增依赖参数，必须修改页面的无参构造函数，违反单一职责原则（页面的职责是展示UI，而非管理ViewModel的依赖）。
• 无法统一管理ViewModel的生命周期，所有ViewModel的生命周期完全由页面控制，难以实现跨页面共享ViewModel实例的需求。

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