As I understand it, razor components runs entirely server side, each method call results in a signalr request to the server and the method called is executed on the server.
In blazor however, the DLLs and the runtime are shipped down to the client and methods are executed in the browser. To make a server call I now need to create an API and make standard API requests.
What I would like to know is, is it possible in blazor to generally execute everything client side as per normal, but for some methods to be executed server side? So a kind of hybrid between blazor and razor components? So doing away with the need for an API?
Razor Components is an obsolete term referring to the Component framework with which you could create either server-side Blazor applications, or client-side applications. It was unsuccessful short-lived term. Currently, the name Blazor is used to refer to the Component framework with which you can create either server-side Blazor applications, or client-side applications. This is actually how we named both kinds of application from the very beginning.
Client-side applications are executed on the browser via WebAssembly. Server-side Blazor application run entirely on the server, and communicate with the browser via SingnalR.
Front-end Blazor applications, generally speaking, require you to create a Web API on the server, and employ Ajax (HttpClient) to communicate with the server.
What model of execution you choose depend on the requirements of your application. Server-Side Blazor application are best suited for Intranet enterprise applications, while client-side Blazor applications are best suited to run across in the public Internet.
Each mode of execution have its advantages and disadvantages.
Hybrid applications, I guess, is possible, but is it, generally speaking, recommended ? When ? How ? It is too early to know... The framework is after all under construction, and patterns of appropriate coding is yet to be formulated in the course of time. But surely you can create a client-side Blazor app which communicate with Web API which exposes SignalR endpoints.(You wanted to know this, right?)
Hope this helps...
Related
In my C# ASP.NET webforms application, there are data access classes which have public methods to insert/delete database records. These are triggered with certain user activity during a browser session.
In order to not reinvent the wheel and to avoid duplicating code, I would like to instantiate these class objects and call those methods from outside the application, possibly using a web service
called from a SQL Server stored procedure, on a monthly schedule using a SQL Server Agent Job.
Is it even possible for a web service to consume these data access public methods in this manner?
Sure, you can adopt some web api's and web methods with webforms.
The $100 quesiton then becomes are you planning to call these web services from another site, or the same site?
I mean, in "most" cases, if this is the same site, then LITTLE reason to go though all that song and dance, since code behind can direcly use that class anyway, and no messay web methods or client side JavaScript is required.
Of course, if one is looking to "spruce" up a given web page, reduce the number of post-backs? Sure, by all means you can adopt ajax calls to those web methods.
You can create a separate page (url) with web service, or you can simple add some web methods to a existing web page.
I often do this (place the web methods in the say web page), since it makes sense to have such code behind in the SAME web page that you will use/want to call such web methods.
And you have quite a few ways to call/consume such web methods.
Built in, they support SOAP calls (XML, not used much these days), or jQuery.AJAX, and they support out of the box both XML and JSON, and do so without any extra coding on your part.
And you can even if you wish use a URL with query parameter's (so, that would be a REST call, and again all of these 3 options work, and work without changes to the web method).
called from a SQL Server stored procedure
Ouch!!! - we were doing so good up to that point!!!
I am not aware that SQL server has ANY provisions for calling web services and web methods. So, a web site with some code behind, or even code that consumes some SQL server data? Sure, no big deal, but this introduction of having SQL server call some web service? gooly gee, no, that is not common, nor even supported as far as I can tell.
What you can do is of course adopt some .net code, and create SQL server stored procedures written in .net code (and that WOULD get you use of web service calls from SQL server).
In other words, you would have to change some of the SQL server permissions (to allow T-SQL to call/consume .net code. This of course is a great option, and is a way to write SQL server stored procedure code in c# (or vb.net).
So, for the most part, SQL server and its code language (T-SQL) certainly does not allow nor have any means to call/consume/use web methods from a web site.
However, if you introduce CLR code to that SQL server (and assuming it supports that option (some hosting sites don't allow CLR code with SQL server. SQL Azure did not for a long time, but I believe of recent, they allow this now, but its a security risk).
is it even possible for a web service to consume these data access public methods in this manner?
If you create and expose some web methods? Then sure, but that is a VAST different issue then SQL server consuming such web methods.
But, yes, can you add/have/create/use/enjoy web methods that you create and add to the webforms site? Yes, that option to create such web methods is quite much a option like near most web systems. You have to of course create + write + setup such web methods, but the answer is yes, of course you can.
And as noted, you can call/use/consume such web methods with JavaScript, jQuery (what I use most), or if that client side code is in the current web page?
then in addition to js and jQuery, you can also use what are called "page methods". This is just a "much" more clean way of calling/using those web methods, but all 3 choices (js, jQuery, js and web method) are available.
I'm going for a coffee break, but I will come back and post the most simple example of how a web method can be created for webforms - it not really much different then other later flavors of asp.net.
I am trying my hands on blazor.Net which is an experimental framework.
I already developed a small project in this Framework and its awesome.
But after recent update in Blazor Language Service on 14 November I am seeing two options in Template selection.
First is Blazor (ASP.NET Core Hosted)
Second is Blazor (Server Side in ASP.NET Core)
There is no information about difference between them,
Can anybody tell me what is difference between these two templates and when should choose which one?
I think the accepted answer does not answer the question asked like Mike-EEE mentioned in one of the comments.
The necessary information can be found under this link:
https://www.telerik.com/blogs/a-breakdown-of-blazor-project-types
The Blazor Full-Stack template encompasses the same project structure as the Client-Side template with a few additions. Just like the Client-Side template there is no HTML rendered by the server and all files are delivered to the client as static files including .NET binaries. The difference however is added ASP.NET Core hosting and Web API and a Shared project for common application logic.
The template includes three projects: a Client-Side Blazor application Blazor.Client, an ASP.NET Core server application Blazor.Server, and a shared .NET Standard project for common application logic Blazor.Shared.
The Blazor Server-Side project template takes a significantly different approach to how a Blazor application is delivered and interacts with the browser. When using the server-side configuration Blazor utilizes the browser as a "thin-client" by deploying a SignalR JavaScript application to the client. On the server, Blazor implements a SignalR hub communicating with the client via web sockets. In the server-side hosting model, Blazor is executed on the server from within an ASP.NET Core app. UI updates, event handling, and JavaScript calls are handled over the SignalR connection. In this configuration there is no need for WebAssembly and Blazor is executed on the ASP.NET Core runtime at the server. All UI updates are sent as diffs, bidirectionally as binary packets over web sockets. To the user, the application is indistinguishable from any other web application.
In the server-side hosting model, Blazor is executed on the server from within an ASP.NET Core app. UI updates, event handling, and JavaScript calls are handled over a SignalR connection.
In the client-side model, the Blazor app, its dependencies, and the .NET runtime are downloaded to the browser, and the app is executed directly on the browser UI thread. All UI updates and event handling happens within the same process.
Pros & cons – read more here.
The server side model was seen as less risky to release first so we will see it first with asp.net 3.0. Client side will come later.
Warning: Do not use in Production code until we get a supported release.
UPDATE
Starting .Net core 3.0, Blazor provides 2 hosting model
Blazor WebAssembly App
Blazor Server App
https://learn.microsoft.com/en-us/aspnet/core/blazor/hosting-models?view=aspnetcore-3.1
Blazor WebAssembly App
The principal hosting model for Blazor is running client-side in the browser on WebAssembly. The Blazor app, its dependencies, and the .NET runtime are downloaded to the browser. The app is executed directly on the browser UI thread. UI updates and event handling occur within the same process. The app's assets are deployed as static files to a web server or service capable of serving static content to clients.
Blazor Server App
With the Blazor Server hosting model, the app is executed on the server from within an ASP.NET Core app. UI updates, event handling, and JavaScript calls are handled over a SignalR connection.
Note: Blazor Server is supported from ASP.NET Core 3.0 and Blazor WebAssembly was officially released during Microsoft build 2020 from .NET Core 3.1.4
Blazor WebAssembly 3.2.0 now available
Here is article that explains it easily:
Client-Side: (First Blazor template in Template Selection):
In this hosting modal the application is executed client-side in the browser. The Blazor app, its dependencies, and the .NET run-time are downloaded to the browser. The app is executed directly on the browser UI thread. UI updates and event handling occur within the same process. This execution modal is available with a preview version of .Net Core.
Since the whole application resides in the browser, DOM updates will
be handled in the browser itself.
Works in offline mode since no server interactions involved.
Not suitable for database connectivity as it required to send
the connection string to the client side which might be a potential security risk.
Debugging is hard as browser DevTools are at the initial stage of
using web assemblies.
The initial page load might be high as all required DLL/Assemblies will be downloaded at the browser.
IE11 is not supported.
ASP.NET Core Hosted (Second Blazor template in Template Selection)
In this hosting modal, the application is executed on the server from within an ASP.NET Core app. UI updates, event handling, and JavaScript calls are handled over a SignalR connection.
DOM updates will be handled in the server part which is hosted in
ASP.NET Core server.
Do not work in offline mode since the signal connection is required for
various actions(Event dispatching, DOM updates etc).
Suitable for database connectivity and operation. You can use Web
APIs to consume and do database operations.
Debugging is not possible for client part as browser DevTools are at
the initial stage of using web assemblies.
Initial page load might be high based on the application side as all
required DLL/Assemblies will be downloaded at the browser.
IE11 is not supported.
Server-side (Third Blazor template in Template Selection)
In this hosting modal, the whole application will reside in the ASP.NET Core server and requests will be made from browser to server for various actions. As this does not send any form of DLL to the browser, it is supported by legacy browsers such as IE11.
DOM updates will be handled in the server part which is hosted in
ASP.NET Core server. SignalR is used for a connection.
Do not work in offline mode since the signal connection is required for
various actions(Event dispatching, DOM updates etc).
Suitable for database connectivity and operation. You can use Web
APIs to consume and do database operations.
Debugging is good. You can use default visual studio debugging
procedure to debug your application.
The initial page load will be good.
IE11 is supported as it does not send WebAssembly to the browsers.
I want to know is it possible to put SignalR's Hub(s) in a different project than Asp.Net project? If it's yes. How can I access to a Hub classes?
Thanks in advance.
As far as I am aware, it is not possible to put a SignalR Hub in anything other than an ASP.NET project, seeing that SignalR is built on the ASP.NET framework, and lives within the ASP.NET namespace. I have not found anything to say anything to the contrary.
However, since Hubs do not need to be in the same project to be accessible for clients, any .NET or Java-Script client can connect to the Hub with the proper amount of configuration.
This link explains how a JavaScript client works:
http://www.asp.net/signalr/overview/signalr-20/hubs-api/hubs-api-guide-javascript-client
If your not using a .NET client to connect, but, say, an external website, tone-in to the Cross-Site Reference section:
http://www.asp.net/signalr/overview/signalr-20/hubs-api/hubs-api-guide-javascript-client#crossdomain
This links explains how a .NET Client such as a Windows Store App, Silverlight, WPF, and console applications work:
http://www.asp.net/signalr/overview/signalr-20/hubs-api/hubs-api-guide-net-client#clientsetup
Seeing as your trying to access a hub in a separate project, which isn't ASP.NET, I would suspect your using a .NET client of some form. The prior link explains how to configure those connections.
So, for example, if your building an .NET client, such as a Windows Store App, it can still access the SignalR Hub located in a ASP.NET project when published, allowing for any real-time functions to work in the client just as it would if the client was within the same ASP.NET project.
I have written a windows forms (.NET C#) application that encodes video and is essentially a GUI for ffmpeg.
The requirement has changed, and we now want to move the UI to a web page and have the encoding done as a windows service.
The following requirements also apply:
Two-way communication between browser's web page and service (i.e. start encoding using web interface and have service notify progress back to web page)
Service should be ported to Mac OS X too
UI should be a standard webpage (should consist of HTML/CSS/JavaScript/Flash etc...)
I was thinking of WCF for the windows service, but I have zero WCF experience.
Will WCF provide a good basis for 2 way communication between the web page and the service?
Also, I need to think about porting the service to Mac OS X, and I noticed that WCF is only partially implemented in Mono (see http://www.mono-project.com/WCF_Development).
Will this be an issue? Does anyone have any experience with WCF development in Mono?
What would be the best route to meeting the requirements above?
I would love to hear any suggestions...
EDIT
I should clarify - this is not a web application, it will run entirely on client side.
Service should run client side and interact with a webpage inside a browser (which is also client side).
If you want a UI in HTML – which is what a "UI to a web page" would mean to most – then WCF is the wrong approach. WCF is for creating highly interoperable (WS-* standards) clients and/or servers; not for web pages.
Better looking at ASP.NET MVC. This is a very different model to WinForms,1 but allows easy moving from from rendering a UI into HTML to generating XML or JSON for a Web API (behind AJAX from a Web UI or a native client).
As I understand it ASP.NET MVC is substantially supported on Mono; and this should become easier with much of ASP.NET being open source now.
See also this answer from yesterday.
1 WinForms would be less of a move, but it would then be harder to do the API side without another technology shift (albeit ASP.NET WebForms and MVC can be easily mixed in one Web App).
I have to pass information from a desktop application to Web application and vice versa.
What are the best practices that are regularly used?
Currrently I'm using Asp.Net and a Winforms.
To pass data to Web Site im creating a (POST) WebRequest and posting an xml to the site.
To pass data to Application im using .Net Remoting from Asp.net
(I'm using Winforms is an adminstration and monitoring application.)
Edit: Lets treat it as a generic web app and winforms.
Also currently both Web app and Winforms are on the same machine.(but can change).
Web Services or Windows Communication Foundation (WCF) would be your best bets for remote interoperability.
On your website, expose some service end points and consume them from your desktop app. Then send messages as you require.
I'd look hard at the design of the system and consider whether it's necessary to use a Winforms application at all for monitoring and administration. No, really: creating rich Web sites is quite straightforward (if necessary, with technologies like AJAX) and the architecture of the resulting application will be much, much simpler.
And, of course, deployment is then really simple.
I am not sure if there is a best practice for what you are trying to accomplish. There might be some security concerns you have to think about when allowing posts to your web application however. It would be very easy for a potential attacker to manipulate the post data and send it to your web application. You should consider using web services or Windows Communication Foundation.
Register a custom handler like how Real player registers rstp:// or for that matter web browsers register http://