Este tutorial fue probado por nuestros especialistas así se asegura la veracidad de nuestro post.
Solución:
Esencialmente hay 3 partes para entender.
Componentes de maquinilla de afeitar
Este es el nombre del modelo de componente principal, fuera de proceso, que se creó en julio de 2018, para la primera versión de Server-side Blazor.
Razor Components es el núcleo del marco y contiene todo lo siguiente.
- Parámetros
- Manejo de eventos
- El enlace de datos
- Enrutamiento
- Inyección de dependencia
- Diseños
- Plantillas
- Valores en cascada
Blazor del lado del servidor
Este es el modelo de hospedaje del lado del servidor, que se ejecuta en ASP.NET Core, para Razor Components. Esta versión aloja el modelo Razor Components en el servidor. Utiliza un tiempo de ejecución pequeño para enviar eventos de UI desde el navegador al servidor. Una vez procesadas por Razor Components, cualquier actualización de la interfaz de usuario se devuelve desde el servidor al navegador y el tiempo de ejecución se encarga de actualizar el DOM. Toda esta comunicación se maneja a través de una conexión SignalR. Incluso las llamadas de interoperabilidad JS se manejan de esta manera.
Blazor del lado del cliente
Este es el modelo de hospedaje del lado del cliente para Razor Components.
En este modelo, todo está alojado en el navegador. Mono, compilado en WebAssembly, es el tiempo de ejecución de .NET. Además de esto, se encuentran Razor Components y, finalmente, la aplicación.
Lo mejor de esta arquitectura es que, en teoría, cualquier función agregada a Razor Components debería estar disponible para ambos modelos de alojamiento. Aunque en realidad, no siempre es así.
¿Que es mejor?
Eso depende mucho de lo que quieras hacer.
El mayor inconveniente de Blazors del lado del cliente es su tamaño de descarga. Esto solo podría descartarlo para muchos desarrolladores. Las descargas se realizan fácilmente en varios MB, por lo que si alguien intenta ver su aplicación en un dispositivo móvil con una conexión lenta, no tendrá una gran experiencia. Sin embargo, vale la pena señalar que después de la primera descarga, gran parte del contenido se almacena en caché, por lo que las cargas posteriores pueden ser de unos 100 kb.
La experiencia de depuración de Blazors del lado del cliente también es muy primitiva en este momento. Lo que significa que trabajar en él como desarrollador puede ser un desafío a veces.
Blazor del lado del servidor tiene una experiencia de desarrollador mucho más agradable en términos de depuración. La aplicación es mucho más rápida de descargar y solo tiene un tamaño de unos pocos 100 kb antes de que se produzca el almacenamiento en caché.
La desventaja es la escalabilidad potencial. Pero esto dependerá en gran medida de la cantidad de usuarios simultáneos que espera. Debido a que este modelo usa SignalR, su aplicación tendrá un límite máximo de conexiones simultáneas. Pero puede administrar esto conectándose a Azure SignalR para permitir una cantidad mucho mayor de conexiones a su aplicación.
En última instancia, ambos modelos de alojamiento de Razor Components tienen un largo camino por recorrer. Las historias de autenticación para ambos son muy tempranas, aunque se puede decir que Blazor del lado del cliente está en un lugar mejor. El motor de enrutamiento aún es limitado, los formularios y la validación acaban de tener su primer lanzamiento y aún queda trabajo por hacer.
Otra cosa a tener en cuenta es que es posible cambiar entre los modelos con bastante facilidad. Entonces, sea cual sea la decisión que tomes, no estás atado a ella. Incluso habrá una forma de hacer esto integrada en el marco en algún momento, por lo que nada de lo que haga ahora se desperdiciará.
Cualquier pregunta, por favor pregunte. Pero espero que esto ayude.
Razor Components es un marco con el que puede crear aplicaciones web SPA. Se divide en dos modos de ejecución. Cuando la aplicación web está alojada y ejecutada en el navegador, se llama Blazor. Las aplicaciones Blazor están escritas en C# y compiladas en ensamblados .NET. Se ejecutan y ejecutan en el navegador como ensamblados .NET por el tiempo de ejecución de Mono, que a su vez se compila en Web Assembly.
El segundo modo de ejecución es del lado del servidor. Es decir, su aplicación web se ejecuta en el servidor, no en el navegador. Tenga en cuenta que aquí el entorno de tiempo de ejecución no es Mono Web Assembly sino el tiempo de ejecución de Asp.net Core. Esto se llama Blazor del lado del servidor, pero también se usa el término Componentes de Razor, por lo que los confundidos se quedan perplejos. La razón de esto es histórica: al principio, solo Blazor se ejecutaba en el navegador. Pero luego surgió la idea de que una aplicación web puede ejecutarse en el servidor y solo las diferencias pueden enviarse al navegador por medio de SignalR. Ejecutar la aplicación web en el servidor es mucho más fácil que ejecutarla en el navegador, y el desarrollador puede usar muchos elementos que no puede usar en el navegador, como la depuración, etc. Como resultado de esta posibilidad, Asp.Net renombró el marco Blazor como componentes Razor, que puede tratar como una superestructura sobre la que se construye Blazor. Por eso la confusión. Hagamos hincapié en esta división de la siguiente manera:
Componentes de Razor –> Blazor (front-end; navegador)
Componentes de Razor –> Componentes de Razor (Blazor del lado del servidor)
Sé que esto es una fuente de confusión, pero esto es todo…
En cuanto a la pregunta de cuál es mejor, solo puedo decir que depende exclusivamente de sus requisitos. Cada uno de estos modos de ejecución tiene sus ventajas e inconvenientes. Las aplicaciones Blazor son más adecuadas para ejecutarse en Internet como sitios web públicos, mientras que las aplicaciones Blazor del lado del servidor se utilizan mejor en la intranet como sitios web empresariales.
La lista que mostró está relacionada con el marco de Razor Components. Algunas mejoras, por el momento, pueden ser solo relevantes para Blazor, otras para Blazor del lado del servidor. Solo hay una forma de saber cuál es cuál: aprender los componentes de Razor. Se necesita tiempo para aprenderlo, menos que Angular, especialmente si eres un desarrollador de .Net, pero aún así es algo que requiere cierta inversión.
Espero que esto ayude… Lo mejoraré más adelante, pero si tienes una pregunta específica, no dudes en preguntar…
Reseñas y valoraciones del artículo
Agradecemos que desees auxiliar nuestra publicación escribiendo un comentario o dejando una valoración te estamos eternamente agradecidos.