I've got a simple thing to do - implement the login form. My employer wants me to use Web forms and my stubborn ass want's to implement the MVC pattern (I already have). The problem is I have no idea how to instantiate the Controller. I run debugging, get the view, but since there is no controller (or model), nothing happens when I click login since no one can respond to the event.
Where and how can I instantiate the Controller?
Yes, you certainly can.
I quote:
"As of 2014, the official answer to this problem is using Web API, as explained in this article I wrote for Simple Talk about a year ago.
Integrating a Web API layer into a Web Forms application couldn’t be easier. You just plug in the Web API runtime, configure routing so that you decide exactly which URLs you want to support and start writing your controller classes in the App_Code folder. Web API follows nearly the same programming model as ASP.NET MVC and is really easy to learn. In the end, it’s just like writing controller classes equipped with public methods callable from JavaScript clients.
ASP.NET Web Forms and ASP.NET MVC share the same runtime environment and requests are routed through exactly the same pipeline. It is even acceptable to say that ASP.NET MVC is just a global HTTP handler installed on the ASP.NET request pipeline. If the incoming request matches the URL requirements supported by the MVC handler then the request is routed to it; otherwise it is processed by the runtime as usual. “As usual” here means just as if it would go in a plain Web Forms application."
Here is the source of my above quoted information. I suggest you give this a read, as this is very useful and will give you a good understanding of the differences between both MVC and WebForms, and how can mix the architectures.
Related
I've never used traditional ASP.NET MVC and started with Nancyfx. I'm considering making the switch to ASP.NET MVC + Web API but have some general questions.
I think I may have been spoiled with Nancyfx but I have some real problems and concerns with it which is why I'm not sure on it for my rewrite. The main problem is the load times. I understand it compiles the Razor views upon first load which extends the load times but there are bugs that cause it to not work (known issues). I've implemented a work-around but I've read that ASP.NET MVC can pre-compile to avoid this situation (Nancyfx cannot).
Doing some research with ASP.NET MVC + Web API it seems the Web API is for the restful endpoints while the ASP.NET MVC is for serving the pages. As you know, Nancyfx combines these two technologies into one which is what is really nice. Am I correct about this or is there a way around to make ASP.NET MVC serve the Razor pages plus serve the JSON/XML requests depending on the request type?
I do not really care to use ASP.NET core to be honest because my application integrates heavily into Active Directory, Microsoft Exchange and other Windows application that are not on other platforms. Someone wanting to deploy it on a Linux server is kind of pointless IMO for what I'm doing.
To put it simply, ASP.NET MVC offers you two controller base classes: Controller and ApiController. You inherit from the Controller class if you want to create view-based controller actions and you inherit from ApiController if you want to create API actions. On the other hand, in ASP.NET Core, you can use the same controller infrastructure to deliver views as well as REST APIs. You can always combine .NET Framework and ASP.NET Core. However, .NET + ASP.NET Core solution works only on Windows about which you apparently have no problem.
I have an ASP.NET Core Web API application that is separate from my ASP.NET Core MVC application (UI). I didn't want to combine them for several reasons since in the future many different clients might need to access the API.
The MVC application makes calls to the API two different ways:
1. Using System.Net.HttpClient in the MVC controllers to populate the View Models.
2. When making jQuery AJAX calls I figured it would be best to directly call the API. (Note: I enabled CORS to allow calls from the MVC application). This would be the same thing as an Angular client making calls directly to the API.
My questions:
Is what I am doing pretty common making calls to the API directly from the client with jQuery and additionally System.Net.HttpClient in the Controllers when not using AJAX and just loading the view data. Should the AJAX calls go to the MVC controller first then let them MVC controller make a DELETE request using System.Net.HttpClient so I am never directly calling the API from the client?
What would the security concerns be? I am a bit nervous calling the API directly from jQuery. I feel like anyone can pretent they are localhost:6000 (my MVC port) and make a DELETE request to localhost:6001/api/users/1 (my API port).
You absolutely correct to be concerned about this. You should be securing your application from this making sure any requests to access these API methods are authorized.
I recommend reading 10 Points to Secure Your ASP.NET MVC Applications. for an overview on how to protect your application from this kind of attack and several other common security vulnerabilities.
I have made a new project using the ASP.NET Web Application template in Visual Studio 2015. Then I selected MVC and Individual User Accounts to specify the template further. The solution I got is complete in that it offers me all the web pages you need for account management such as registering and logging in.
However, now I want to hook in a Xamarin.Forms mobile client to this account management scheme. I am making a native UI to register users, instead of redirecting them to a webpage or webview. I want to send user registration data, such as username and password, from this UI to the server so it will create an account. This means that I don't want to use the webpages offered by my MVC app, but rather send the registration data to the server and have it create an account, notfifying me of succes or failure.
I am anticipating that I would need to either use HTTP POSTs to login and registration endpoints in the AccountController or implement a public API. However, doing a post will return a webpage, and my client is not interested in a webpage.
I think one of the above should be possible to implement quite easily, but I am having a hard time searching for answers or methods, since I don't know how to phrase my problem properly, and with the abundance of guides on MVC, all my results are muddied.
Is my idea of this being possible flawed or have I missed a fundamental concept of MVC? What are the steps I should take in order to make this possible?
One misconception is that doing a POST will return a webpage. You can return any type of content from an MVC controller. But your account registration endpoints should be Web API controllers that return JSON. That JSON can be as simple as containing a boolean that indicates if the action was successful or not.
You do not need to use MVC at all. You can completely do away with the account controllers and views that the template created for you. Just copy the code that you need from the MVC controllers into your Web API methods.
You're right, this is quite easy to do.
I think, You can use ASP.NET Web API for doing this task. On server, you host your API for registering the users as well as logging into some client application.
Now, You need to consume this API in a client application. The client application could be a Console application, Windows application or a Web application. There are lots of tutorials about making an Web API on official ASP.NET site.
i need to write website, that must have private part in single page application and public part that must be in classic style(to the best indexing by searching engines) with Ajax support without usage CORS or JSONP. All logic must be in service (RESTful) style, for future mobile apps support. So i decide to use ASP.NET MVC and ASP.NET Web API in one project(to prevent CORS or JSONP), i planning to use asp.net mvc controllers to return template html for private part and whole html for public part. I don't want to put any logic to asp.net mvc controllers except get some data (dictionary collections) for public part views. So is see two possible solution for that.
Create ApiController and try to get data from it method
Don't like that, because it destroy RESTful style and SoC (it's need to pass IUnityOfWofk implementation to asp.net mvc controller constructor under DI, to redirect it to constructor of ApiController)
Like that because it don't need to spent time to http request same host (localhost).
Get data under http request to ApiController in MVC controller.
Like that beacuse RESTful and SoC is OK.
Don't like that becuase it spent time to http request to same host(localhost).
My questions are:
What else possible solutions can be to solve my task (in .Net platform) ?
How http request to same host (localhost) in asp.net mvc controller may influence the delay in time for the client browser (public part), it is criticaly for response time ?
What is the best solution 1 or 2 ?
Another option is to factor out your logic from the Web API controller to a separate class model and use it both in the MVC and the Web API controllers, e.g. by injecting the instances of the relevant logic classes into the controllers. You'd also be able to share the Unit of Work.
Of course, this adds another layer of complexity, but at the same time leads to a better Separation of Concerns. After all, MVC and Web API are only a way to present your logic to specific clients. In case of Web API, the main responsibility of the Web API layer is to create a RESTful interface to your logic; handling the logic itself is not a task of the Web API layer if you are very strict.
I'd favor this approach over the others as these approaches have some downsides (numbers as in your question):
Create ApiController: you need to mimic the Web API environment very well. Though this is possible, it also means that changes on the Web API side of things will have an effect on the implementation of your logic.
Make a HTTP request to the Web API:
Though a request to the same server in the MVC controllers might be relatively quick and therefore not critical, it will take some time that is not necessary if you can just have a call to some shared classes.
Also, the HTTP request adds a point where your system might break.
In addition, you wouldn't be able to share a Unit of Work with the Web API.
I have an asp.net mvc application and now I need to add a web service to go along with it. What is the best solution for this? Just create a new web service project and add it to my solution then deploy it to the same web server using a different url? I would like it to be a part of the mvc application only because I have all my database code in there.
Any suggestions would be appreciated. Thanks.
There's no reason not to add a web service project.
You state that all your database code is in your MVC project. I strongly recommend you remove it from there into a separate class library project. This third project would be used both by the web service and by the MVC application.
I also strongly recommend that you not use ASMX web services for any new development.
Use WCF only, unless you have no choice at all. There's a misconception that WCF services don't do SOAP - they do, and WCF has replaced ASMX.
Web service could mean a soap based web service or a RESTful web service. I can't think of any reason why you would not be able to simply add an asmx file to your project and be in business. That is the soap based route. If you want to be really cool though you can simple return xml from a controller action and implement a RESTful solution right over the MVC framework.
If you want to use a regular ASP.NET asmx web service, it's certainly possible. Here's an example from Scott Hanselman that does just what you are asking about and it throws in some other ASP.NET technologies for good measure.
All you have to do is File -> New Item -> Web Service and it should work like a regular ASP.NET application in your Mvc project.
i think there's a couple of things here.
you can indeed add a web service to an MVC application. you may even consider identifying the web service(s) as a script service to make REST like operations easier to perform via javascript. this may not be necessary due to your circumstances.
i think there is a stronger question as to the underlying architecture. If you are placing the web service withing your mvc application, because, your database code is already there...should it be? it might be a good time to abstract your data layer out a little. However, if you're dealing with a relatively small project and don't need the flexibilty, then certainly, add a web service right in. i guess what it really boils down to is addressing the true needs of your application.
MVC is built on the asp.net framework. You should be able to include a web service within the same project. I haven't done it but I know that you can combine asp.net forms applications with MVC applications in the same project. The same should go for web services.
Unless your application is very small I would recommend you create different projects for each logical part of the application. A good staring point is having a project for each of these:
Domain objects
Data access
Web Services
UI (your ASP.NET MVC app)
This provides a clean separation corresponding to your architecture and supports reuse.