What is the architecture difference between working with razor vs blazor?
Documentation suggest that I have to write an Web Api when using blazor - is it still possible to pass model objects like in traditional razor ?
0 Video with visual explanation
I decided to make a video, since several questions about Blazor were asked (also on other forums) and this format seems much better for me to visualize the differences - instead of reding my (longer) explanation. The video contains a bit improved version, compared to my first post (the text post is also updated) It's one of my first videos in this format, so any feedback is welcome. If you prefer to read a classic text without much visualization, you'll find it's content in the following sections. Of course without the demos, which I made to lighten the content up, but the basic information content is the same.
1. What is a traditional multi-page site or application?
First you need to have a basic understanding how traditional websites/apps works: For every call/request, you send a request to the server and the server responds with the complete HTML of the entire page. This can be dynamically generated like with ASP.NET Core MVC and Razor templates or Razor Pages or even some other technique like PHP, Java, Python and so on. Let's say you have a list of articles showing a preview.
To illustrate this, let's say you have a list of articles (for example blog posts) showing a preview. When the user clicks on read all, you usually have two ways to realize this in traditional web apps:
Load a page like /view-article?id=123 where the above happens again: Loading the entire HTML DOM of the article page
Using JavaScript to make an Ajax-Request, which loads the desired content from an API like /api/get-article?id=123 and manipulate the DOM to display it at the desired position
Without JavaScript, traditional sites are not interactive. This means: After the page is loaded and rendered, nothing happens any more – except the user load another page (with the entire DOM) by clicking on a link – for that reason, it’s called „multi-page“ application.
You'll propably prefer the second approach, cause it's faster and saves ressources: Instead of rendering the entire page again (where only a part of it has changed), you stay on that page and just load the new information you need (the article content in this example). Especially on large pages with many ressources to load and render, the JavaScript approach feels much faster to the user.
If you like traditional pages to be interactive, you need JavaScript. For example you can add an ajax call to some API that displays some data when the user clicks a button, without having to reload the entire page.
In short we can say, that most of the work happens here on the server side.
2. Where is the difference to single-page applications (SPA)?
SPAs have just a single page, in terms of a full rendered html page. If you navigate there like by clicking on article, they load a JavaScript application. It handles everything interactive there. If the user clicks on an article, there is NO complete HTML document fetched from the server! Instead, it only fetches the parts who are changed, in this case the article. Everything else (e.g. navigation bar, footer, widgets etc) will remain - in opposite th multi-page apps, where this may be reloaded if no js/ajax is used.
You often have modulary components there and two-way data binding. This means, a variable is linked to some HTML element. When the variable changes, the element automatically displays the new value. In traditional apps, you'd have to create event handlers manually to handle this. It can be seen as continued development of a single page application with vanilla JavaScript, where you need more manual work to archive things like data-binding.
For the user, a SPA normally is much faster than navigating through pages on multi-page apps.
In short we can say, that most of the work happens here on the client side in the browser of the user. The server just serves static stuff (html, js, css) and provides APIs for e.g. fetching entries from the DB or save them.
3. What has Blazor to do with that?
A Blazor app actually is a SPA. But the main difference to other frameworks is, that Blazor lets you control both the client and server side with C# code. To show that benefit, let's look at other SPA frameworks like Angular: You can build an Angular SPA with ASP.NET Core. In this case, you write your client side in Angular with TypeScript. If you need to access data, it will make API calls to the ASP.NET Core server, which is C#. It will be similar with other frameworks like React, but here with JavaScript instead of TypeScript.
This make it hard to share code between those two: If you have an article model, it needs to be defined in C# on the server and in TypeScript on the client as well. With Blazor you just define it once in C# and re-use it on both sites. In other words: You just write C# without having to care about JavaScript*
*That’s the basic idea behind Blazor: Use C# everywhere, without the need for JavaScript as second technology. But it’s worth mentioning that you need to work with Blazor components to accomplish this. If you need some library not being ported to Blazor yet, you still have to handle a bit of JS. However, there are still benefits like the data binding. Using it on an entire plain JS stack would be some work, so I’d recommend to start with an UI library that offers Blazor components.
3.1 Blazor WebAssembly and Blazor Server
Now you know the basics and you need to decide between two flavours:
Blazor WebAssembly
As the name suggests, it basically uses WebAssembly to run your C# browser directly in the browser. It requires a relatively recent Browser and is not yet supported on all platforms/browsers. Also major engines like Chromium or Safari doesn't support all standardized features yet.
Let's say you have a button with C# code as handler like this:
<button class="btn btn-primary" #onclick="IncrementCount">Click me</button>
IncrementCount is a C# method. The code got transfered to the client and would be executed in the browser. Imagine it as .NET Core runtime inside the browser, like Silverlight BUT without any external plugins. There is no need to even have ASP.NET Core on the server-side! It can be served from any webserver, as long as you don't need things like DBs from the server side. This makes the app larger (and slower, at least on the first load).
The example Visual Studio template has a size of more than 17 Megabyte! With compression this can be reduced to 7 Megabyte – still a lot for a hello world application. By publishing the application in release mode, this goes down to about 7 MB and 2.4 MB with gzip.
At least subsequent requests are faster. Those DLL files are stored in the browser cache, which avoids further requests.
But it can be used offline (at least the main logic without API calls). For that reason, it's sometimes called real SPA – it’s compareable to Angular, React and other client-side frameworks.
Because of the WebAssembly-Usage, Debugging can be harder here, currently it just support Chromium based browsers.
Don’t know WebAssembly? It’s a relatively new, open standard that generates bytecode to improve loading and execution time to realize more powerfull web-applications – independent of the language. You’re not forced to use specific languages like JavaScript: Since Bytecode is generated, also other languages like C++ or Rust can be used.
In a nutshell, WebAssembly can be seen as next generation JavaScript for feature-rich webapps, where Blazor WebAssembly is the C# implementation. Because of the browser runtime, there are some APIs which can’t be used here. For example sockets or I/O access, like File.Open or File.Write.
Blazor Server
The app runs on the server and just transfers the output (like the result of a click event, that increases some counter in another HTML element) to the browser using SignalR Websockets. This makes the app smaller and faster, but requires more ressources on the server-side cause you have a SignalR connection and it's virtual DOM also on your server - making it harder to scale in large setups.
On the other side, this reduces the requirements on the clients: They don't need to support WASM, so it could run on older browsers or browsers with restricted WASM support as well as low-end devices. But since every action ends in a SignalR call, the app won't work offline - if this is a requirement, choose Blazor WebAssembly over Blazor Server.
What to choose?
It depends on your needs, as pointed out above. For example, if you need offline support, Blazor server wouldn't be a good choice. If you're unsure I'd prefer Blazor Server and only really worry about this if you're planning to deploy a very large application.
Imho, Blazor server is currently smoother and more flexible. Blazor Server also got stable before WebAssembly. This recommendation may changes in the future, when WebAssembly has developed further and got more widely supported.
But in this case, you can migrate later!
Both Blazor WebAssembly and Server use Razor components. This means: You can change between both, without re-writing your entire code. Some migration work is only required for things like data-calls outside the browser when migrating from Blazor Server to Blazor WebAssembly. The reason is, that Blazor WASM runs entirely in the browser, so you need a server part like an ASP.NET Core API projekt to handle them.
Further information
I recommend the Introduction to ASP.NET Core Blazor in the official documentation. Also the other chapter describing a lot of information about the platform and offers tutorials. They go deepter in detail to topics like data binding or event-handling to just name a few, and illustrating them with examples. I tried to kept it shorter here for a basic overview.
See also: Blazor WebAssembly 3.2.0 and ASP.NET Core 5
Having a JS web application (ASP.NET MVC, talking via REST with the server) I cannot use the server-side ReportViewer Control to open reports generated by the Microsoft Reporting Services.
I am searching for ways to open reports without making the Reporting Services public. It is no option to pregenerate the reports and just linking them.
My first idea was setting a route to a server-side controller that creates a web request (calling Reporting Services with all necessary parameters), caches the response and returns it to the client. But I am not sure if this will be the best solutions.
Does anybody had the same task and might share his/her solution?
Thank you!
Oskar
In fact, reports may have subreports, which have to load data from the server it's the best choice to use the ReportViewer Control. So the solution is to create an plain old Web Forms APSX having this control included until there will be an updated/new control from Microsoft. This works pretty good.
With no postbacks ReportExecution2005.Render will be your friend. Drop the report viewer and create a scheme that works for you:) Telerik controls just released a MVC viewer control but.
Already, I implemented a BaseReportController in conjunction with a BaseReportModel in conjunction with a BaseReportView that includes paging, exporting, refreshing etc. etc.
Pain in the ass...please let me know when there is something better.
I am in the process of developing several data entry forms that the client has asked to be accessible through the SharePoint interface (2007 WSS version).
The forms will, among other requirements, consist of multiple drop downs that have to be loaded from tables in SQL Server. These lists of data are updated frequently through a process that sucks data in from Great Plains.
My inclination is to create a Web Part Page with a Page Viewer Web Part and go full screen like this: http://blogs.msdn.com/b/malag/archive/2008/09/15/story-of-a-mischievous-page-viewer-web-part.aspx
...and then to do the pages in ASP.NET MVC3. Is there a better story than this? The integrated SP development paradigm seems like waaaay more overhead.
This sounds like a common issue with developers new the SharePoint paradigm, especially for 2007. The short answer is that your solution will be the quickest way to get to where you want to go but isn't the "cleanest".
The other option is to create a SharePoint Solution and publish an application page to the _layouts directory. A quintessential "hello world" example can be found at http://msdn.microsoft.com/en-us/library/bb418732(office.12).aspx.
New SP developers will find the hardest transition with deployment. The WSPBuilder codeplex project http://wspbuilder.codeplex.com/ has become the industries default solution for doing this. An example of using this can be found at http://www.greggalipeau.com/category/sharepoint/wspbuilder/.
For you I would say the key words are Application Pages and WSPBuilder.
I would like to have a custom web part page in SharePoint 2007. I have an application that uses javascript to popup a new window with a web part page. Currently this web part page inherits the look and feel of the site (the default.master). I would like a web part page that i stripped down so that it is almost empty (I guess I still need the ability to add web parts etc.).
Is there a way to do this?
Best regards
Pål Eilertsen
It seems that it was easy to do. I only needed to create a new masterpage and use that one instead. Then I could save the SharePoint site as a template and in code create all the sites I needed, and the new masterpage would follow.
I'm learning SharePoint development.
I read some general how to build a web part, but I'm wondering what a web part is in general?
Big picture, why are they used, what problem is it solving?
Think of a Web Part as a reusable custom web control that is placed, positioned, and whose attributes are set in the browser instead of in Visual Studio. Since SharePoint places such a high priority on customization and content authoring, there needs to be a way for a non-developer to add or modify controls on the web page. Web Parts are that way.