Share via


Riutilizzare Razor i componenti in ASP.NET Core Blazor Hybrid

Nota

Questa non è la versione più recente di questo articolo. Per la versione corrente, vedere la versione .NET 8 di questo articolo.

Importante

Queste informazioni si riferiscono a un prodotto non definitive che può essere modificato in modo sostanziale prima che venga rilasciato commercialmente. Microsoft non riconosce alcuna garanzia, espressa o implicita, in merito alle informazioni qui fornite.

Per la versione corrente, vedere la versione .NET 8 di questo articolo.

Questo articolo illustra come creare e organizzare Razor i componenti per il Web e Web Views nelle Blazor Hybrid app.

Razor i componenti funzionano tra modelli di hosting (Blazor WebAssembly, Blazor Servere in Web View di Blazor Hybrid) e tra piattaforme (Android, iOS e Windows). I modelli di hosting e le piattaforme hanno funzionalità uniche che i componenti possono sfruttare, ma i componenti eseguiti tra modelli di hosting e piattaforme devono sfruttare separatamente funzionalità univoche, come illustrato negli esempi seguenti:

  • Blazor WebAssembly supporta l'interoperabilità javaScript (JS) sincrona, che non è supportata dal canale di comunicazione di interoperabilità strettamente asincrono JS in Blazor Server e Web Views delle Blazor Hybrid app.
  • I componenti di un'app Blazor Server possono accedere ai servizi disponibili solo nel server, ad esempio un contesto di database Entity Framework.
  • I componenti in un BlazorWebView possono accedere direttamente alle funzionalità dei dispositivi mobili e desktop native, ad esempio i servizi di georilevazione. Blazor Server e Blazor WebAssembly le app devono basarsi su interfacce API Web di app su server esterni per fornire funzionalità simili.

Principi di progettazione

Per creare Razor componenti che possono funzionare senza problemi tra modelli di hosting e piattaforme, rispettare i principi di progettazione seguenti:

  • Inserire il codice dell'interfaccia utente condiviso nelle Razor librerie di classi (RCL), ovvero contenitori progettati per mantenere parti riutilizzabili dell'interfaccia utente per l'uso in diversi modelli di hosting e piattaforme.
  • Le implementazioni di funzionalità univoche non devono esistere nelle DLL. Al contrario, l'RCL deve definire astrazioni (interfacce e classi di base) che ospitano modelli e piattaforme implementati.
  • Acconsentire esplicitamente solo a funzionalità univoche ospitando il modello o la piattaforma. Ad esempio, Blazor WebAssembly supporta l'uso di IJSInProcessRuntime e IJSInProcessObjectReference in un componente come ottimizzazione, ma li usa solo con cast condizionali e implementazioni di fallback che si basano sulle astrazioni universali IJSRuntime e astrazioni supportate da tutti i modelli e IJSObjectReference le piattaforme di hosting. Per altre informazioni su IJSInProcessRuntime, vedere Chiamare le funzioni JavaScript dai metodi .NET in ASP.NET Core Blazor. Per altre informazioni su IJSInProcessObjectReference, vedere Chiamare metodi .NET da funzioni JavaScript in ASP.NET Core Blazor.
  • Come regola generale, usare CSS per lo stile HTML nei componenti. Il caso più comune è la coerenza nell'aspetto di un'app. Nelle posizioni in cui gli stili dell'interfaccia utente devono differire tra i modelli di hosting o le piattaforme, usare CSS per applicare uno stile alle differenze.
  • Se una parte dell'interfaccia utente richiede contenuto aggiuntivo o diverso per un modello o una piattaforma di hosting di destinazione, il contenuto può essere incapsulato all'interno di un componente ed eseguito il rendering all'interno dell'RCL usando DynamicComponent. È anche possibile fornire un'interfaccia utente aggiuntiva ai componenti tramite RenderFragment istanze. Per altre informazioni su RenderFragment, vedere Rendering di frammenti di contenuto figlio e Rendering di frammenti per la logica di rendering riutilizzabile.

Organizzazione del codice del progetto

Il più possibile, inserire il codice e il contenuto statico nelle Razor librerie di classi (RCL). Ogni modello di hosting o piattaforma fa riferimento all'RCL e registra le singole implementazioni nella raccolta di servizi dell'app che un Razor componente potrebbe richiedere.

Ogni assembly di destinazione deve contenere solo il codice specifico per il modello di hosting o la piattaforma insieme al codice che consente di eseguire il bootstrap dell'app.

Blazor WebAssembly, Blazor Servere WebView dispongono di un riferimento al progetto per la Razor libreria di classi (RCL).

Usare astrazioni per caratteristiche univoche

L'esempio seguente illustra come usare un'astrazione per un servizio di georilevazione ospitando il modello e la piattaforma.

  • In una Razor libreria di classi (RCL) usata dall'app per ottenere i dati di georilevazione per la posizione dell'utente su una mappa, il MapComponentRazor componente inserisce un'astrazione ILocationService del servizio.
  • App.Web per Blazor WebAssembly i progetti e Blazor Server implementano ILocationService come WebLocationService, che usa le chiamate API Web per ottenere i dati di georilevazione.
  • App.Desktopper .NET MAUI, WPF e Windows Form, implementare ILocationService come DesktopLocationService. DesktopLocationService usa funzionalità specifiche della piattaforma per ottenere i dati di georilevazione.

In una libreria di Razor classi (RCL), MapComponent inserisce un servizio ILocationService. Separatamente, App.Web (Blazor WebAssembly e Blazor Server progetti) implementano ILocationService come WebLocationService. Separatamente, App.Desktop (.NET MAUI, WPF, Windows Form) implementano ILocationService come DesktopLocationService.

.NET MAUIBlazor codice specifico della piattaforma

Un modello comune in consiste nel .NET MAUI creare implementazioni separate per piattaforme diverse, ad esempio la definizione di classi parziali con implementazioni specifiche della piattaforma. Ad esempio, vedere il diagramma seguente, in cui le classi parziali per CameraService vengono implementate in ognuna di CameraService.Windows.cs, CameraService.iOS.cs, CameraService.Android.cse CameraService.cs:

Le classi parziali per Fotocamera Service vengono implementate in ogni Fotocamera Service.Windows.cs, Fotocamera Service.iOS.cs, Fotocamera Service.Android.cs e Fotocamera Service.cs.

Se si vogliono inserire funzionalità specifiche della piattaforma in una libreria di classi che può essere utilizzata da altre app, è consigliabile seguire un approccio simile a quello descritto nell'esempio precedente e creare un'astrazione per il Razor componente:

  • Posizionare il componente in una libreria di Razor classi (RCL).
  • Da una libreria di .NET MAUI classi fare riferimento a RCL e creare le implementazioni specifiche della piattaforma.
  • All'interno dell'app che usa, fare riferimento alla .NET MAUI libreria di classi.

L'esempio seguente illustra i concetti per le immagini in un'app che organizza le fotografie:

  • Un'app .NET MAUIBlazor Hybrid usa InputPhoto da un RCL a cui fa riferimento.
  • L'app .NET MAUI fa anche riferimento a una .NET MAUI libreria di classi.
  • InputPhoto nell'RCL inserisce un'interfaccia ICameraService , definita nell'RCL.
  • CameraService le implementazioni parziali della classe per ICameraService si trovano nella .NET MAUI libreria di classi (CameraService.Windows.cs, CameraService.iOS.cs, CameraService.Android.cs), che fa riferimento all'RCL.

Un'app .NET MAUIBlazor Hybrid usa InputPhoto da una Razor libreria di classi (RCL) a cui fa riferimento. L'app .NET MAUI fa anche riferimento a una .NET MAUI libreria di classi. InputPhoto nell'RCL inserisce un'interfaccia I Fotocamera Service definita nell'RCL. Fotocamera Service implementazioni parziali della classe per I Fotocamera Service si trovano nella .NET MAUI libreria di classi (Fotocamera Service.Windows.cs, Fotocamera Service.iOS.cs Fotocamera Service.Android.cs), che fa riferimento all'RCL.

Risorse aggiuntive