I've been reading up on MVC2 which came in VS2010 and it sounds pretty interesting. I'm actually in the middle of a large multi-tenant application project, and have just started coding the UI. I'm considering changing to MVC as I'm not that far along at this point. I have some questions about the Routing capabilities, namely are they required to use MVC or can I more or less ignore Routing? Or do I have to setup a default routing record that will make things work like standard ASPX (as far as routing alone is concerned)?
The reason why I don't want to use Routing is because I've already defined a custom URL 'rewrite' mechanism of my own (which fires on session_start). In addition, I'm using jquery and opens-standards for the entire UI, and MVC's aspx overhead-free approach seems like a better fit based on how I've already started to build the application (I am not using viewstate at all, for example).
I guess my big concern is whether the routing can be ignored, of if I will have to re-implement my custom URL rewriting to work with MVC, and if that's the case, how would I do that? As a new Routing routine, or stick with the session_start (if that's even possible?).
Lastly, I don't want to use anything even remotely 'intelligent/readable' for the url - for a site like StackOverflow, the readability of the URL is a positive, but the opposite is true if it's not a public website like this one. In fact, it would seem to me that the more friendly MVC routing URL (which indirectly show method names) could pose a security risk on a private, non-public website app like I'm developing.
For all these reasons I would love to use the lightweight aspects of MVC but skip the Routing entirely - is this possible?
You could make it work without routing, but you would have to rebuild a lot of the framework and pretty much build your own routing engine. That wouldn't really make any sense as Microsoft already provide you with a great routing framework. All your url rewriting rules could easily be implemented using the routing framework anyway. You don't have to have the action name of the controller name in the url if you use the routing framework. As long as you can tell what action should be executed from the raw url it could be implemented.
My advice would be to read up on the routing framework and learn how it works. I'm pretty sure you will not regret it.
Don't bypass routing
Routing is imperative part of Asp.net MVC and ignoring it will cause more or less trouble. You could get by by using ISS7 URL Rewriting module, but it will only work if your requests have a certain format, otherwise you will end up writing rewrites for every single request that is used in your app.
The good thing is that routing is nothing you should be afraid and is quite simple to understand as long as you don't start havind some complex routing rules. Then you will delve even deeper into it and probably love it even more.
Related
I have two projects. One is an ASP.NET Mvc, and the other is a Web API.
The main project is the Mvc one. But I need to redirect the request to the Web API. All posts about it make clear that in order to redirect to another project, it should be a Redirect to an URL:
return Redirect("http://localhost:54270/"); //This calls the Get action in the Web API
But the problem is that I'm using an Authentication in Mvc that I would like to be validated in the called Web Api Action. Is it possible?
The session is not the same, so I cannot retrieve this information. Is there any way to share the same Context between both running sites? Or is it the wrong approach?
Yes, it can be done. In webforms, you can set the keys to hash values to the same key in multiple applications. As long as they are in the same domain, that is all you have to do. I have not tried it in MVC, but the internals are very similar. This is a bit of a kludge, but it works nicely.
In this simple way of doing it, you cannot share information, just the high level session information. As I have not played with this in MVC, you may have to set MAC settings or similar to get it to work. I don't have time to look this up. When I found this worked, the developers were still thinking in the ASP world, so they had a boatload of crap in the Session object which we had to sync up. You should not have this issue.
This method will not share the contents of session, but that should not be an issue if you are using MVC correctly.
If you want to go beyond this, there are ways to set up a single sign on mechanism. Anything that works for ASP.NET webforms should work in MVC, although you may have to add some code for items that would not normally be set in MVC that are required for webforms.
If you want a deeper understanding of the way it works, I would look up how people shared state in ASP and ASP.NET, as these pages generally have more information.
First time asp.net webAPI + angular project. From many examples I've seen online I've found there are basically two ways for handling the views.
The first (which I have seen in many tutorials and courses) - use APIcontrollers only, so that the view are generated by angular. That means my project structure would have a folder 'app' and it will contain the html files (probably inside a 'view' folder). The routing will be done using angular routes. I will only have APIControllers in the project (without the regular Controller object).
Example project: https://github.com/DanWahlin/CustomerManagerStandard
The second - using Controllers to generate the views, using Razor (cshtml files), and angular incorporated into those (i.e ng-click inside the cshtml). There's no special 'app' folder for angular etc.
example project : https://github.com/Wintellect/Angular-MVC-Cookbook/tree/master/CRUDOperations
So, I'm wondering what are the pros and cons for each method, and when shall I use which one. Examples projects would be great as well.
I can only assume that the first method is more modular and differentiate server and client. However, using it means I'm loosing razor (Do I even need it?)
Thanks!
I actually had to make this decision a few months back myself.
This comes down to what you feel is more comfortable. I chose to do angular and WebAPI controls only. It makes me think in terms of true separation of concerns just easier, angular is your presentation layer and webapi is your services. This also gives you the freedom to do the compression/formatting of the actual html pages(instead of the cshtml pages which you really have no control over).
One more pro for WebAPI only is scalability, you would really only need one webserver for the webpages but you can scale out your WebAPI, this will allow you WebAPI to be your api as well as your clients as well.
Razor is just a view engine and in my experience angular does a good job of templating and directives to bear the cost of losing razor. You'll probably end up writing pure HTML in your razor files anyways once you get a hang of directives which means you'll have more of an issue adding a new view. Who wants to create a new controller, new action and a new view, and then have to do that in angular. It just ends up being easier and less complex to let server serve the html files, and let angular do all your routing and logic for you.
I believe too that the html files get cached too so you will see less round trips as you navigate page to page in angular.
As a person who works at a Microsoft shop and loves AngularJS for nearly all my front-end, the sooner you get away from mixing Razor and AngularJS, the better, especially if you are going for a SPA.
The only time I would recommend using Razor at all would be to generate the landing page (and possibly login page/admin area). It does give a nice way to provide authentication to access the app and then use Web Api Authorization attributes to do the rest of the authentication.
I am working on an web application/site and I want to do it with AngularJS, ASP.NET and Typescript.
I read about the Single Page Application concept, but I still have some question about this whole concept:
Why should I prefer a SPA (Single Page Application) before multiple pages.
I also have some questions about integrating it with ASP.NET:
In ASP.NET it standard generate a nice bootstrap layout with about 3 pages at the top. So I think that it means that I need to combine all these pages to one page. But how can I get it to work together with the routing of ASP.NET. Because you will use the routing of AngularJS, and I want to keep the login from ASP.NET (Can you maybe give an example so I can see how it works).
If I got it correctly Typescript in this concept will replace the JSON webservice. Is this correct or do I got this all wrong?
If you could answer one of my questions I would be very thankful.
SPA's are a trend, they are mostly useful to move the load on your server to the clients. Only data requests will be made to the server, rendering is done on the client machine.
There are still other benefits, but I guess this is the most relevant.
As to your questions regarding integration into ASP.NET.
Building an SPA does not mean all has to fit in one page. Look at AngularJS, it will fetch views as separate requests (see templateUrl in routingprovider). That being said, you can use ASP.NET MVC and serve ASP.NET Views as Angular Templates. This allows for a neat separation of Model, View and Controller parts.
Typescript is Microsoft's JavaScript dialect. It will not replace JSON and you will probably want to use JSON to exchange data with your server. You could use XML, but that is a little bit oldfashioned (and way more bulky).
I have no experience with TypeScript so I would not consider doing that (coffee might be a better alternative), but there are also some quicks in JavaScript you need to be aware of. I would suggest to search Douglas Crockford and Javascript on Youtube. The guy has great talks that can make you a JavaScript pro.
I have a reasonably large project at work that I've inherited. It's an ASP.NET 2005 website project and two C# library projects for data access and some business logic. The code actually runs 6 different database driven websites. It displays different images and text for each site based on logic that examines the URL and uses a series of Web.config values and switch statements.
We now have several new websites that will follow the same pattern and framework as these 6 and so management has decided that we should not reinvent the wheel and we should continue to extend the existing code. While I understand the decision from their perspective, the thought of extending this code with even more Web.config values and even more switch statements throughout feels wrong. It seems like there should be a better way to manage this particular form of complexity, but I don't have a handle on what that better way should be.
At the same time, I've been looking for a project to start learning ASP.NET MVC and I've been leaning towards re-developing this project with it on my own time since it's complex, but the requirements are in the code. I'm looking to gain 3 things out of moving it to MVC: 1) be able to test the app and all it's versions and all it's dark corners that I don't even know exist yet, 2) hopefully find a way to make managing about 12 sites on a single code base manageable and 3) learn MVC.
After rambling a bit, here are some specific questions:
Will MVC actually offer me better ways to manage the 12 site in 1 code base issue? It's a bit hard for me to tell without having a deeper knowledge of MVC.
Is there a templating pattern or framework that I can apply (in either WebForms or MVC) that is suited for sites like these that have similar content and structure and run from the same code base?
Is there a better way than examining the URL to decide which site is being viewed and what the images and text should be displayed for each site?
Thanks for the time. I do appreciate it!
ASP.Net MVC might have some real advantages for you here. You wouldn't be manually examining URL's any more, because the Routing functionality of MVC would do it for you - so in a way, it is a "better way". Here are some advantages:
URL routing is an easy way to differentiate which site was being served, and your "which site am I" parameters would be automatically handed down to every Controller (and subsequently, every View) if you structured your routes correctly.
URL Routing works both ways, so it would be relatively straightforward for you to define a single View for all your sites that generated proper images and script references to whichever site directory you needed.
Partial Views would be a great way to switch in site-specific content in corner cases where the template wasn't exactly the same for each site.
As long as the logic was reasonably similar for each site, ASP.Net MVC 1.0 could handle this. If you need different controller logic for each site, the upcoming release of ASP.Net MVC has the concept of "areas", which would allow you to implement different sites in the same application that all had their own Controller, Model and View directories - but were differentiated by their routes.
Will MVC actually offer me better ways to manage the 12 site in 1 code base issue?
Honestly: I would not go this road. ASP.NET is powerfull enough to have a multitennant system. There are things that help to build multitennant applications in ASP.NET MVC. You have IoC for changing business rules between applications and you have the option to dynamically choose which view to render.
You have testabillity.
Thats all great: read here about it
link so
But still: It is an enourmous effort to implement such a system. ASP.NET is great (you got Routing now!) and if you have a running system better invest your time in making it better.
I am making a making a new asp.net web forms site and would like to beautify my urls - I want to accept a url like this one "www.mysite.com/1-2,3" and turn it one like this "www.mysite.com/page.aspx?a=1&b=2&c=3". Which option is best for this task - IIS7 Url Rewriting or Routing in terms of performance and ease of maintenance. Btw I am planning to use medium trust shared hosting IIS7, maybe 6.
In the past I used PHP's mod_rewrite, which I was quite happy with, however now this whole site is being translated to ASP.NET, and I don't know which option to pick.
PS - I have already read this and this, however didn't find it clear enough for my problem.
I would make a strong argument for using routing. It keeps the request-resource resolution logic within your application, so it's very easy to add application-dependent logic when you need, and it eliminates the need to maintain synchronization between your application and a separate configuration resource.
Routing works great with traditional webforms.
URL rewriting is often (though not always) a compensation for a problem, rather than a solution - server software and frameworks still built around the older notion of web pages, which represent physical resources. However, web applications should react to requests as commands; but only relatively recent, modern web frameworks have begun to support that model natively. Routing is one of those developments.
I would strongly suggest to use routing,
it will in fact be more integrated with webforms in next version of the framework.
URL rewriting is more of a "hack" due to the lack of the routing in the first place. If you already have a project that you want to "shine up", then url rewriting will do just fine.
But when starting from scratch, I would definitely use routing.
Routing hides you application structure and makes you think more of your urls, as path to the content that you want to show, opposed to the path to some page with params.
And you don't have to keep track of 2 things when changing stuff, like you would with rewriting.
more in this article
IIS 5/6 used ISAPI filtering which was basically the equivalent of mod_rewrite for IIS. I hear that IIS7's url rewriting is a lot easier to manage and configure than ISAPI.
Well it depends on whether you're using classic ASP.Net or the new MVC framework. I don't have any experience with the MVC framework, but it sounds like it supports what you're looking for right out of the box.
On the classic ASP.Net side of things, we're currently using an IIS extension called ISAPI_Rewrite. It behaves similarly to Apache's mod_Rewrite and they have a free version you can use that has most of the power of the paid version ($100).