We have an existing Application in ASP.Net (Aspx Pages), we are thinking to integrate new functionality in MVC. This is something that we can easily do it through the several examples available on the Internet.
Here, the main question is "What if we want to integrate MVC project with Angular?" We could not find any example or blog related to the same.
Is it possible? What are the pros and cons of it? How we can achieve it?
We are totally blank in this, any help would be appreciated.
Note: We do not have any code because we haven't found anything.
You have to consider following things at least:
Routing (Angular has its own routing configuration which can be tweaked if needed).
Angular (not AngularJS) uses TypeScript. So, in your existing ASP.NET project, you have to ensure that your TypeScript files are transpiled into JS.
Since you say that the existing ASP.NET project is working, it might make sense to think about why you would like to do this, what your objectives are.
AFAIK, using Angular in ASP.NET project directly (without using MVC alongside) makes more sense.
I think you can do the following:
Use Angular for client-side rendering, calling HTTP
APIs and UX. Angular allows re-usable components written in TypeScript and makes architecture modular.
Continue with ASP.NET for server-side processing and security.
Related
I am looking for a way to use HTML, CSS, JS Framework like Angular or Vue in the front page and use C# without ASP.NET in the backend to develop Single Page Applications. Is there any possible way to do it? I mean can we use C# without ASP.NET in the backend as an API and develop Single Page APPS?
I googled it a lot but did not find any helpful resources so I came here to get help of the stackoverflow experience.
Thanks in advance for any help.
Yes, ASP.NET is an entirely optional part of a .NET web application.
Depending on how you want to host it, you can just let your code work in an Owin middleware, an IIS module or handler or a plain old HttpListener, and so on, causing "raw" HTTP requests to end up in your code.
You can then mix and match features from ASP.NET or third-party libraries such as routing, security, content negotiation (serialization), bundling and minification and effectively you'll be creating a Frankenstein monster that won't work as well as ASP.NET and that others can barely maintain.
At least one such framework already exists and is called "Nancy", and has all the drawbacks mentioned above, in addition to a barely maintained and poorly debuggable cousin of Razor.
So the answer is "yes, but why?".
I am a beginner in web development and I want to start a new ASP.NET Core project and I have some questions regarding the structure of the project and what is the best practice. So, my goal is to make a website using razor pages and web API all together. I thought about 2 options:
To make different projects for the API and for the razor pages and between them to make a C# library that has an API Helper which sends the HTTP requests to the API project.
To put the API and the razor pages in the same project. I think this option is much simpler but I have some concerns. How to call the API? (I saw that you can use jQuery or in the same way I can make an API Helper class). If I use jQuery for API call can I do the validation in C# before jQuery send the data to the API?
Another thing I want to ask is should I use Identity for authentication? I don`t want default pages and tables in my database when I do the migration. I want to customize them. I know that I can modify the Identity classes and pages if I scaffold them but I want to do it manually. I also know that making such an authentication system could be challenging but I want to learn how to do it.
To sum up, I am curious to know how are ASP.NET CORE web projects structured in development and I want to know some best practices to do all these things. Thank you in advance!
I think you maybe misunderstand how razor pages works. Its a purely server-side rendering system. The client requests a page from the server, and the razor pages renders the whole page and sends the resulting HTML, CSS, JS to the client browser. This means you dont need to think of an API as a separate piece really. Unless you want to make it more complicated, a Razor Pages website will be a single project, where each page has two files, a View (.cshtml) file which combines c# and html to build the web page, and a backing .cs file which handles the routing and assembling of data to provide to the view, along with handling authentication etc.
As for authentication, I recommend you go with Identity if you plan on actually deploying this live, rolling your own authentication system out is difficult and error prone, and Identity is easy to customize to your particular needs, while also giving a good and secure starting point.
We are currently considering moving from ASP.NET MVC to Angular 5, mostly because it seems like the best and latest framework. However none of us seems to be able to come up with hard reasons on why Angular is better than MVC (Razor).
SPA vs MPA seems like different approaches with neither really being better - just better at different things.
Are there any resources/comparisons with hard benefits between the two?
Update: Almost 2 years after moving to Angular 4 (currently 7) I can say that it was a great decision. Angular makes it super easy to write quite complex front-end applications and the tooling around Angular itself, TypeScript, Karma + Jasmine (unit test frameworks) is fantastic. SPA is a huge step ahead of MPA in my opinion - we can finally have fluid web experience. I never really liked Razor and the whole mess around ajax/jquery, but I can comfortably say that I am really enjoying my time now! .NET CORE 3 + Angular 7 gives us everything we need!
To anyone thinking of taking the plunge, I would strongly recommend Angular (might as well start with 8 or 9, which is current at the time of writing this).
Happy to add more details if people want them :)
6 months on from moving from ASP.NET MVC to Angular 5 (now 6) and we are extremely happy with the decision. .NET core backend and Angular frontend is a fantastic combination. It is so much cleaner and easier to create re-usable, strongly-typed, testable and easy to modify UI components!
For anyone considering if it's worth taking the plunge - I would say a resounding 'yes'!
I don't have enough points to make a comment but thought the following might help you in making a decision.
Just to note that if you use Angular CLI (The default Angular project in Visual Studio) you will lose the ability to use razor within the HTML. Something you was able to do before Angular CLI.
I do like using Angular but miss having Razor to omit certain parts of the HTML, for example, if the user didn't have the necessary roles or permissions:
#if(User.IsInRole("Admin"))
{
}
You can hide the HTML using Angular of course, but having it completely removed from the HTML itself is preferable in my opinion.
I vote for an ASP.Net MVC Web Application in the cloud [Core or whichever] , and use of razor pages as needed. That is it. Case closed.
Even if the whole world runs after Angular , Aurelia, React, Node, Strawberry, Pistachio, butterscotch JS, I will not.
After all, JavaScript is spagetti and Angular is the Flying Spagetti Monster
based on personal experience and intuitive take.
Now please don't get started about mouse hover over page areas,
What I did found out about Angular vs MVC (Razor), I can work with both :-)
Authorization: One thing to make sure is that you don't have complex authorization schemes. On the backend its easy to do your authorization on pages with Razor (even more with Core). Its more difficult to handle authorization with Angular because you will have to do it (and keep in sync) on both sides: client and server. Example: One thing you want is hide everything a user is not allowed to do. If you have a simple webapp and use a Masterpage: show only the menu items a user is allowed to see. Thats a very easy task to do in Razor. It takes more time/effort to implement this in Angular.
Templates: Razor is extremely easy to use with templates. If you develop a website that must be used a number of times but with different layouts that can be done very easily with Razor.
Maintenance: With MVC you have one application. The frontend and backend are one. For maintenance you will have a Angular frontend and X Backend, so two. That seems more costly from installation, maintenance, etc. point. If you have a simple application I would say KISS: Keep It Simple Suckers.
One: In MVC the frontend and backend belong together. That can be good or bad. If you have one application with no dependencies on other things I think MVC is a good choice.
Future proof: Angular is NO W3C and NOT baked in the browser. Because of Future proof solutions there is a strong interest in Vanilla Javascript together with Web Components. With MVC you can use this technology. Read about Microsoft FAST Design. It works great with MVC.
SPA/MPA: Thats not a point anymore. An MPA can also be flicker-free with libraries like PJAX etc.
Speed: With MVC no wait time because Shit has to be loaded. Enough bad Angular websites already exists because loading takes ages.
...: After working with Angular 9 I don't get the point of Angular. I don't know why you should go from MVC to Angular. Visual Studio has great support for MVC and is much better as VS Code. From productivity point I can produce much faster code with MVC as with Angular. If you have multiple front ends that must connect to the same backend may be then I can see the point. But even then MVC can be moduled and even can dynamically load them.
htmx Wow, now we are talking! Yes this is what we want. Let Html take back control how pages are loaded. Think this is the way to go. Worked a sample with NodeJS and are very exited about it.
Update: I just did a nodejs/express/mongodb project and it beats it all. I am an expert mvc developer, but developing faster, better on a chromebook of 220e with vs code. now I know why it's so popular. and guess what? it's free. and guess what else? part of dotnet Core is based on nodejs. the console app is the same as a nodejs server. both you will have to put behind a proxy of IIS, Apache or NGINX.
One thing that I learnt during the comparison of MVC and Angular, among various factors, is that hosting MVC application requires a compute power container like Azure Web App, docker etc, while an Angular App can be deployed in any storage like Blob, CDN etc. When Angular is built, it gives a collection of javascript files, which are perfect candidate for storage container. They do not need compute power at all, which are the most costly resource in cloud world. CDN or Blob exposes Rest API endpoint to any of its underlying resource. So, the Angular will also be exposed as an API, which is all we want.
However, angular alone will not generate dynamic web pages. We need Web-Api at back-end to give the data. This can be achieved by a server-less solution (Function Apps, Logic Apps etc) or by containerization (Docker).
One downside that I personally found that the first time load of the Page in Angular is bit slow. After that it is really smooth.
All in all, I will vote for Angular/React and .Net Core in my future Web projects.
I am creating a new website and web api. Using the VS2013 template I select the webapi template (with individual login). The template creates a mvc asp site.
Is there anything wrong with having my website in the same project as my web api or should I create two projects in my solution. One for the API and one for the website?
I am thinking of allowing a desktop app to use the api as well.
As Brian said there is nothing wrong, but it is not only about code organization, if you host them in same project then there is no need to enable CORS for API if you are building SPA (issuing XHR requests from browser), they both will be on the same domain.
As well from security perceptive it will get complicated because you will use cookies for the MVC application and bearer tokens for the API. I'm not big fan for the VS 2013 Web API template with individual accounts because it add lots of middle wares and boilerplate code that you might need to use or not aware of its functionality.
My recommendation is to separate them from the beginning and have control on both projects.
You can read more on how to build API from scratch and components you need here.
No there is nothing "wrong" with including the WebAPI code in the ASP.NET MVC project. At its simplest, having the WebAPI in a separate project is merely code organization, having any code in another project is about code organization. If your project is small, will remain small, and you are the only one working on the project than it really is fine to leave API in the same project as the ASP.NET MVC website.
However, if you expect other people to work on the project, if you expect the code base to grow. Than you should organize your code well from the start and place the WebAPI in a separate project.
But for a shorter answer: it is wrong, you should always be tightly organizing your code at every moment or it will get out of control, be disorganized and hard to maintain in the future.
So put the WebAPI in a separate class library project.
I'm currently working on a project that has a sizable amount of both client and web code. The client code is written in C# and the web piece is written in PHP. Maintaining consistency between the two worlds is becoming cumbersome, and I want to consolidate the web code to .Net.
The issue is that I hate web development in ASP.Net Web Forms. I want something as raw as PHP, just using C# instead. I've read a little about ASP.Net MVC, but it looks like it abstracts too much of the request logic for my liking.
Does anyone know of a lightweight way to allow C# + .Net to handle web requests? Should I be looking more closely at MVC?
Update: I went with ASP.Net MVC and I've been very pleased so far.
If you're looking to get away from ASP.NET Web Forms, the I recommend ASP.NET MVC with a custom view engine (like Spark, or NHaml). This will give you the consolidation your looking for and allow you to avoid most of the Web Forms that your not happy with.
AFAIK, to do .NET web development, you are going to have to interact with ASP.NET in some form or another, but the custom view engines in MVC could be exactly the abstraction your looking for.
It is now possible to use a software stack completely separate to IIS and ASP.Net using Kyak, Nancy and Gate.
http://bvanderveen.com/a/gate-0.1.0/
You might want to check out Kayak, which is, to my knowledge, the only standalone .NET web development framework that's not ASP.NET.
Caveat: Kayak's request handling implementation is not the best, so there may be performance or scaling issues. I can't say for sure -- I've only read it, not run it.
Edit: I've taken another look at the source code, and it looks like they've rewritten a significant portion of their server code, and in doing so fixed the major issues. Performance probably won't be a problem.
MVC.NET is open source, so you can make it do what you want. It is a framework that is overrideable, extensible, etc. I'd look closer at it. It works great for me and I've come from a background of CGI, Struts and Webwork. I love it.
In my opinion nothing is more lightweight than the combination of NancyFX (http://nancyfx.org/) with Dapper (https://github.com/SamSaffron/dapper-dot-net) for data access.
NancyFX can be hosted within ASP.NET, WCF, Azure, OWIN-compatible environments, Umbraco or you can write your own host.
Read also these articles:
http://theothersideofcode.com/lightweight-development-in-dot-net-nancy
http://theothersideofcode.com/lightweight-data-access-in-dot-net-massive
I also suggest you to TinyIoC (https://github.com/grumpydev/TinyIoC) for decouple your application layers.
Regards,
Giacomo
You should look into the IHttpHandler and IHttpModule interfaces. These are the foundations for ASP.NET WebForms. Brad Wilson has a good intro to the former.
In the bad days when WebForms was the way to do ASP.NET development I was writing my own simple MVC framework with these interfaces. The bit I struggled with at the time was the View engine but now there are a number of these.
You take a closer look at ASP.NET MVC since the source is available and decide for yourself. It may be that you want to change some of the conventions used rather than the whole framework.