We have a large web based application that is built on ASP.Net MVC. We also have a public website that is just HTML/Javascript except for a couple places where we need to submit some information for back end processing. Case # 1 is a simple contact form submission. If that was the extent of it, I'd just process the from via PHP and be done. Case #2, however is more complicated. I need to save data to a database, run a Crystal Report, export the report as a PDF, email the PDF, and send results back to the browser. I already have the ability to do all these tasks on the ASP.Net MVC application. So here's my question. How do I leverage the code I already have in .Net MVC my web app from my public HTML/Javascript site?
I do not want to use ASP.Net MVC on the public site because I don't want to change the routing of the public website.
I have identified two possibilities so far:
1) Submit to a webforms ASPX page. The downside of this approach is that the Web Forms way of doing things creates extra files that I don't need such as designer files, plus I have to consider things like viewstate and postback.
2) Create a Web Service. I don't really know a lot about this, but I have done a little research. If I go this route do I use WCF Service or a Web Service? What are the pros and cons of using this method over the above listed method of submitting to an ASPX page? Is a webservice overkill for what I am trying to do?
Are there other alternatives besides what I have thought of?
Note: I am only interested in the server side aspect of this. I already know I will be using JQuery and AJAX to submit the post and receive back the results. Also business logic is already in a seprate project so that is not a concern either.
Related
I'm an angular beginner and am currently working through a few angular tutorials. I have some ASP.NET MVC experience from a few years back.
What I think I am trying to understand is whether I should be attempting to design my application as a SINGLE or MULTI page application.
As far as I understand, there are two main schools of thought, when it comes to Angular and ASP.NET CORE applications:
Create a simple ASP.NET CORE application serving a single page. That page will be a single-page angular application, which will take care of its own routing, etc, presenting a variety of different views and potentially using an API exposed through ASP.NET for data
Create a multi-page ASP.NET CORE application, serving a number of different pages, each of which will be a razor page, with some part of it being an angular application
Am I understanding this right? I think the single-page application makes sense to me, but I do find that I am quite confused on multi-page approach... I am not quite clear on which part of multi-page application is angular supposed to fill and whether every single page should be its own angular application.
I have tried searching for a comparison of the two, but was unable to find anything decent. :(
In Multi-Page Applications, the client (browser) which typically sends a request for page to the server to initiates the communication. Then the server processes the request and sends the HTML of the page to the client (browser). For every request server sends the full html to the client, not to load patch html to the client.
In Single-Page Applications (SPAs) at first the entire page is loaded in the client by the initial request, after that the subsequent action has to update by Ajax request and no need to reload the entire page. The SPA reduces the time by to respond to user actions and result is more fluid experience.
I don't think the classification you use is correct.
To me it is:
Traditional "multi page" application: HTML generated on server (ie MVC and Razor) and pushed to the browser at every request.
Single page applications (SPA): HTML downloaded a single time from the server and manipulated on client via Javascript (ie Angular).
Probably you are talking about "multiple" "single page applications" where you break a complex SPA into smaller ones.
Ie you could have a "user" SPA and an "admin" SPA published from the same website.
If you want to build single page application(ajax based) in Asp.net Core MVC solution without using any third party JavaScript framework then better you have to look this github repository.
https://github.com/KishorNaik/Sol_Ajax_Spa_MVC_Core
I've explored the ASP.net web API framework and MVC 4. I understand the point of using web API that only return data then in client side we use javascript, ajax to handle all actions via HTTP verbs. On the other hand, MVC controller can return data and view we can handle event via [HttpPost] in controller.
I saw some people they make 2 projects in a solution: one is Web API in MVC 4 and the other is MVC 4 Internet Application. Is it a good idea? I didnt see the relation between two kind of projects. Can anyone explain me the how two project can communicate with each other, and what is the advantage and disadvantage of that way?
Note: in this solution he/she still uses Httppost to handle event and use MVC controller return view with Model binding.
Well I guess this is going to be a pragmatic conversation...
For starters, it seems like the Asp.net WebApi and Asp.net MVC are going to be aligned in Asp.Net V-Next, so there is going to be One base controller class that will return what ever datatype you wish (ActionResult, Json etc).
And from the recent years experience I think the trend is to have a WebApi that exposes data and a portal(client) that is just a JS web application with no C# code that just calls the Api from the browser and does what it needs to do.
So that way we basically save one hup to the server(the MVC server) and we can directly call the API from the browser.
However some people would still argue about load balancing, scaling, caching etc that you could have if you keep the MVC tier there but still all those things could be done in the WebApi and JS application too...
So long story short, I think if you want to move with the trend I think you should go with a RESTful API and have your client to call it from the browser directly with JavaScript...
For many developers ASP.NET and ASP.NET Web Forms are the same things. For some time I've been using Web Forms, but recently I learned that Web Forms is only build on top of ASP.NET. I become more curious how does a simple plain ASP.NET application look like. I learned about 3 ASP.NET programming models: Web Forms, Web Pages and MVC (Here Scott Hanselman explains briefly the differences). But it still seams that all the 3 approaches sits on top of ASP.NET.
I was trying to find an example application which uses pure ASP.NET, but I couldn't find anything.
I started to dig deeper into source code of ASP.NET web page and I found out that each web page is actually HTTP Handler (each page implements IHTTPHandler interface). Does it mean that pure ASP.NET application would be just a HTTP Handler implementation? Or am I missing something.
In my understanding ASP.NET Web Forms correspond to Win Forms in desktop world. But in the desktop world you can still write console application which doesn't use Win Forms. So what is an equivalent of console application in the web world?
Any comments or references appreciated. Thanks in advance.
ASP.NET is a very broad set of technologies, and it includes WebForms.. and as of MVC5, it also includes MVC, WebApi and WebPages. This is what Microsoft is now calling the "One ASP.NET" initiative.
These are all part of ASP.NET, just like ASP.NET is part of .NET. These are all just layers. There is no 'seperate' part called asp.net that does not contain these pieces (and even in earlier versions, there was no version of asp.net that did not include WebForms).
As such, there's no such thing as a "pure asp.net" app. You can certainly write an app that does not use WebForms (which means no .aspx or ascx or .master files, no Server Controls of any kind... essentially anything that exists in the System.Web.UI namespace.)
At most, you could consider this whatever is in the System.Web namespace (without any further levels of namespaces. Essentially what's here http://msdn.microsoft.com/en-us/library/system.web.aspx )
So that would be things like the Request object, the Response object, Cookie handling, Membership, FormsAuthentication, etc... This is basic plumbing that isn't all that useful by itself. You would have to write a presentation framework of your own to sit on top of it.
There are other frameworks out there, such as FubuMVC, Nancy, MonoRail, etc... these are just like MVC or WebForms or WebPages... using the basic ASP.NET classes to do their job.
I would like to refer you, as an example, to ASP.NET MVC.
ASP.NET MVC is a framework on top of ASP.NET but is definitely not Web Forms (in fact, it replaces it completely, and to my opinion - for the best).
ASP.NET provides services common to web in general, things such as:
Handling requests and responses
Security, Authentication, Impersonation etc.
Maintaining an 'Application' (the notion of Global.asax for example as a framework around instansiating apps, shutting them down, handling central things such as Routes, handling uncaught exceptions etc.)
Taking care of hosting permissions
Physical & virtual apps
Interfacing with IIS (or other web servers) in general
Running Modules (in addition to HTTP Handlers)
Web Forms adds a presentation layer on top of ASP.NET's infrastructure. It provides things such as Forms, ViewState and such. "Translating" code-behind code to HTML representation for example. This are just few examples.
The separation between ASP.NET as an infrastructure and Web Forms as a presentation layer allowed creating ASP.NET MVC later on. ASP.NET MVC does not rely on 'Forms' at all, does not try to mimic WinForms development workflows (by obscuring raw HTML using code-behind "methods" and "properties" and such) and in fact provides a much better & correct way to do web development.
You were asking about pure ASP.NET. Here is an example of pure ASP.NET, no WebForms, no MVC. Here is one: http://support.microsoft.com/kb/308001 . It's a basic HTTP Handler that, in this example, runs every time your browse to some address ending with .sync (by "teaching" ASP.NET to handle every request that uses that extension).
By the way, you can treat it as a "console" app (in your terms). It gets a URL, no matter where from (you can use curl if you like) and returns a text response, and that's all.
The current codebase at work is entirely WebForms, with most logic being stuffed into the code-behind file. I'm investigating the possibility of using MVC3 for new pages added and future refactoring without having to throw the entire codebase away (a big no-no). All of these pages are part of the same "application" so it's not as simple as just creating new projects with MVC - they have to interact very closely, and in some cases WebForms pages will have to redirect to MVC pages, and vice versa.
I've come across a few articles that show how it's possible to integrate the two (albeit in very simple scenarios, while my scenario is fairly complex), but are there any issues to be aware of? Specifically in regards to going from a WebForms page to an MVC page and then back to a WebForms page, where data is required to be passed across pages say from the Session (and not necessarily read entirely from a database upon load), for example a workflow like:
(WebForms) User goes to CreateQuote.aspx?CustomerId=42 and enters some data. They click a "Process" button...
(MVC) /customers/42/process MVC page that reads in the information submitted before, and does some extra things. User hits a "Next" button...
(WebForms) CompleteQuote.aspx?CustomerId=42&QuoteId=534235 page that pulls out information from the previous MVC page and applies more logic to it.
Also, our existing project is an ASP.NET Web Site project (i.e. the one where every individual page is its own DLL); would it have to be converted to a Web Application project to exist side by side with MVC (that alone is a major refactoring effort due to large clumps of duplicate code across code-behind files)?
I would recommend you to avoid mixing ASP.NET MVC and classic WebForms in the same application. Keep them in separate projects and make them communicate through standard HTTP protocol mechanisms (query string parameters, form posts, cookies, ...). You could share authentication between them if they are hosted on the same domain. You could even share session objects between them even if they are hosted in separate application pools in IIS (not that you should be using session at all, but that's another topic).
As far as reusing the data access logic is concerned, well, depending on how properly your existing WebForms application is designed, you could share the assembly that contains your current data access code. And if your existing application is poorly designed with strong coupling between the different layers, you could wrap this legacy code behind a repository and still reuse at least the database access code.
By keeping your applications separate you don't need to pollute your new ASP.NET MVC application with references to some legacy code and you don't need to pollute your existing application classic WebForms application with ASP.NET MVC specific things.
I have an existing Asp.Net MVC Website and I would also like to provide a Web Service from the same domain.
What is the best way to approach creating a web service in this scenerio?
Do I add to this project or...?
You should be able to add an WebService file directly to the MVC project.
Right click on solution and select add new item, then select the web category and att the bottom of the list there should be Web Service.
Just remember to check that the routes does not eat up the call to the webservice.
That way the webservice can get access to the same model classes as the MVC application.
You can add a web service to the project just as you do in regular ASP.NET web apps, however, MVC basically IS a web service. You could create a controller that handles all the requests that you want your web service to handle.
With the advent of MVC it is quite common to do applications that only ever load a view once, then use AJAX and client scripting almost the entire rest of the life of the application. Your AJAX calls just hit up action methods for their goods and then use the deliciousness that is JSON to parse the data and utilize it.
In my opinion designing a web service as a controller instead of using [WebMethods] is far simpler and a lot more fun!
First, the question is "what do we mean by web service?" This can mean anything from a MVC page that responds using XML, JSON or some other agreed upon format to full blown SOAP and WS-* encumbered nightmares.
Anyhow, perhaps the best place to start is the WCF restful services -- these play very nicely with MVC, including routing.
The cool kids are using openrasta.