This is an odd question, and it just occurred to me today. I've been trying to convert an ASP Classic application for a couple of years now into .NET Webforms, which I knew way back when.
The ASP Classic app in question is pretty much a CRUD app, but I've added over the years a lot of jQuery and Ajax, so it's pretty responsive and behaves the way I'd like, so it's not a fill form, post to page type of app. I'm still developing that one in parallel with the .NET one as new features are required.
In any case, the WebForms that I go back and look at is cluttered with ViewState and controls named weird and total crap.
I don't have a lot of time coming up - tight dev schedules - so I was thinking about using the WebForms without ViewState so I can essentially pull over the Ajax and jQuery code from the ASP pages and use .NET almost like ASP with the benefit being the debugging and the extensive libraries of data access and business logic components I've written in .NET for standalone console apps.
Again, tight schedule. I've got an isolated portion of the app in ASP.NET (Administrator Pages), so I could dump ViewState and be able to start reusing front-end code.
Is this an ok approach in transition? I'm not sure yet what my ultimate platform will be (MVC or WebForms)
Is there anything else I must do besides disable ViewState to make my code behave and for page elements to not do anything "funky" like rename controls or insert code?
Related
I want to reuse a project developed in vb.net in c# webform project. The login form should be same for both the projects. How can I achieve this? Can I add vb.net and C# forms in single project.
If created as separate projects in single solution, can I share the session variable between two projects?
I want a common login form for c# and vb.net project. Need to share user credentials between two apps
Well, you can intermix pages of vb and c# only if the web site is NOT a web site application.
So, it kind of depends.
If your web site is setup as a website application? Then no, you can't do this.
You can certainly take any of the code modules, classes, and business logic from the vb.net applcation, and refreence such assemblies in the new c# project.
And its not really recommended to do this anyway (ie: mix both types of pages in one project - but, you can do this for a web site, but not for web site applications).
I see VERY but VERY little advantage to simple re-writing all that code. It not like your going to get more features, or anything of value here.
If you looking to migrate to .net core, MVC etc? Then again, those pages could not be used anyway - even if they were written in C#.
So, either you consider this a migration project out of webforms (and .net 4.8), or you don't. Anything in-between is really a waste of time and resouces. If that site is to continue running as webforms, then I can't really make the case to migrate the code to c# - I just don't see any benefits here.
So, this can work for a asp.net web site, but not for a asp.net website "application".
And, I always hands down preferred the "application" choice, since then things like including other projects and code (often written in c#) can be used and is supported.
But, a page with code behind in vb.net, mixed in with pages and code behind in c#? No, you can't do this with a web site application, and giving up the application choice (vs that of a web site) I think is too high of a price to pay in that you lose out of the benefits of a asp.net application choice in the first place.
This sounds like good money after bad. Unless you going to migrate to a newer framework? It makes VERY little sense to spend time + money to migrate to JUST c#, and I can't see any real benefits of doing so.
if the developers in question know well asp.net + webforms, then the learning curve to maintain the site "as is" with vb.net? I can't see more then a day or so for any good c# developer to get up to speed with vb.net.
c# or vb.net is really moot - what matters is a good solid skill set in the .net framework, and unless you jumping over to .net core, then as noted, I can't see how the cost of this work can be justified. it in effect amounts to stealing money from those paying for this conversion, and that means someone is being mislead, or miss informed here.
i have recently converted a classic asp application to ASP.NET 3.5, but i feel that my Classic ASP version was a bit faster (i don't know may be buyers remorse).
So can you guys help me with this and let me know which one is faster, asp, asp.net or ASP.NET MVC.
I searched for this question on so and didn't find anything, if you find anything, please point to that question and mark my question as duplicate
Thank you guys.
Classic ASP will interpret the script for a page on every page request. ASP.NET will compile the code for the page once. ASP.NET will almost always perform better than classic ASP. ASP.NET MVC is simply a (better?) way to write ASP.NET applications.
Also, in my oppinion the features ASP.NET is far superior to classic ASP. You should be able to spend fewer developer resources on creating a more complex website if you choose ASP.NET.
As ASP uses interpreted code and ASP.NET uses compiled code, ASP.NET is waaaay faster to execute code.
However, this does not automaticaly mean that an ASP.NET application always is faster than an ASP application. A lot of the performance depends on database efficiency and how much data you send between the server and the browser.
When using ASP.NET webforms, it's easy to get a lot of overhead in the viewstate that is send back and forth between the server and browser, which is probably why you don't see much of an improvement in your application.
ASP.NET MVC doesn't have the same form of controls that uses viewstate, so you won't accumulate overhead as easily.
It's always a bit of a sin to say "x is faster than y" but I think this is an instance where I can say Classic ASP is slower than ASP.net, excluding a few edge cases you might be able to find, one of the main reasons being Classic ASP is interpreted and ASP.net is compiled.
In terms of performance, Classic ASP is definitely slower, for the simple reason that ASP.Net is compiled, and Classic ASP is intepreted.
ASP.Net MVC and ASP.Net WebForms both build on top of IHttpHandler (the basis of the Page object used in MVC/WebForms)
Using ASP.Net WebForms or ASP.Net MVC, you can use HttpHandler to serve things up faster (.ashx). Further reading
ASP.Net WebForms is often heavier (slower) on the client-side due to some bloated client-side framework (heavy JS libraries) and conventions suchs as the ViewState.
Further Reading
Some things in ASP.NET are not as simple to do without writing much code. I believe if your ASP code was faster and you're doing simple things then you're better of staying with it. I still build in classic ASP if i can get it done faster than ASP.NET.
I feel .NET is for complex sites or projects where only the best will suffice..but i may be wrong. In ASP you can do a lot of bastardization the client wants.
Classic ASP is an interpreted scripting language. ASP.NET compiles down to machine code, so it will most likely be significantly faster (there might be some edge cases and wierdo optimizations in Classic ASP).
ASP.NET MVC is just a thin layer on top of ASP.NET Runtime.
People automatically assume that a compiled application will ALWAYS run faster than an interpreted application. While that's generally true, (C# code will almost always run exponentially faster than VBScript), you have to look at the other dependencies that exist and the environment in which the application is run.
In reality, most of the time there's a negligible difference in a simple web application where you're requesting a web page, grabbing it's associated data from a database and then returning it to the browser. Requesting and returning data from the database probably consumes at least 60% of the processing of the page, another 30% is the web server creating the response.
Example, a poorly designed SQL query will slow down your app exponentially more than the chosen language you're using. Remember, it's all about the algorithm!
Trying to be objective here, but I've noticed only negligible difference in returning the same data to the same web page with ASP.NET MVC with C# and ASP. I think you'd see the same results with Spring MVC or PHP, or even ASP.NET MVC with Visual Basic.
That said, I would prefer to use ASP.NET MVC everytime because it gives me the option of using asynchronous controllers and asynchronous actions. I also like to design an application with meaningful objects. It's impossible to do ASP with OOP unless your writing the back end in C++ with ActiveX, which is an ugly solution for modern applications.
ASP doesn't lend itself well to SOC (Separation of Concerns), so most ASP apps resemble a kitchen sink with a weeks worth of dirty dishes.
I have been learning to develop websites using ASP.NET MVC 2 for work... and previous to this, I had never developed within an .NET environment before. Since I jumped right into using MVC, I honestly have no idea how else to develop websites with ASP.NET.
I've heard about "WebForms" here and there, but don't really get the difference. But, beyond that, what other means of web development is there with ASP.NET?
It's all very backwards, I know... but if you can just humor me and perhaps list the different ways of utilizing C# to develop great web applications, that would be extremely useful.
ASP.NET is the platform for developing .NET web applications.
Sitting on top of that platform is two technologies to choose from:
ASP.NET Web Forms
ASP.NET MVC
Web Forms uses WinForms-style development - drag/drop, event handlers, page lifecycle, statefulness with ViewState - all things evil in my opinion.
MVC as you know has no page lifecycle, no event handlers, no server controls (you can, but not recommended/required), no ViewState.
Don't really know what else i can say without going into too much detail.
Both technologies will be continued to be supported/enhanced.
But since your already versed in ASP.NET MVC - i seen no benefit in learning Web Forms. It would be a step back if anything.
As for this statement:
just humor me and perhaps list the different ways of utilizing C# to develop great web applications
That's a bit too broad/subjective.
What is "great"? Well performing? Looks good? Maintainable? All of the above?
No doubt - MVC will do a better job at most things than Web Forms.
Only feasible choice for a Web Forms app might be a intranet application where tons of complex grids/controls are required, and things like SEO/AJAX is not required.
Everything else should be done in MVC IMO.
I have a client that currently has a shopping cart written in ASP that he wants to keep using. We are looking at upgrading the rest of the site to DotNetNuke which is based on ASP.Net.
Does anyone have any guidance on how to use asp pages in an asp.net application? IFrames? I did a little ASP just before dotnet came out, so I"m not that familiar with ASP.
You can combine them pretty easily, you will just need to have the asp have its own global.asa and session timing. As long as your authentication logic is simple, you can write it in both, or consume it as a service from the asp pages.
The main concerns are shared state amongst pages. IFrames are viable options, but hard to get to look natural.
I'm currently doing this in an application that is half converted, its 170 aspx pages, and 210 asp pages.
That said, the context switching of maintaining both parts, is painful. So try and get it rewritten, quickly. On MVC its fairly trivial to have the logic flow like asp.
You can mix the two, but I don't think you'll be able to do things like share state between them unless you cater for this with a third party provider. They'll behave more like two "seperate" sites.
One other thing worth mentioning is that if you are provisioning a new web server for the mix, and planning to pull in the old ASP code, is that ASP is not enabled default on the more recent versions of IIS.
You can't use ASP pages in an ASP.NET application.
You can have an ASP application and an ASP.NET application in the same web site, but they are still two different applications. They work side by side, basically unaware of each other.
You can have the pages communicating with each other, and even use iframes to seamingly mix them in the same page, but communication is not trivial as the web applications can't communicate directly. You can communicate between them on the client side, or through a common backend database (or any other indirect way that you can think of...).
You would be much better off using a single ASP.NET solution.
There is a DNN shopping cart module available from here. There is supposed to be a community edition. [I haven't used it, so can't say how good it is]
Most asp is going to valid as asp.net. You may be able to rename your .asp pages to .aspx and get 80-90% of the old code working under asp.net. Then fix anything that's broken and slowly migrate more and more of the old code to proper asp.net.
We are about to embark on a large enterprise application. I am seriously considering using ASP.NET MVC because:
We need to use Microsoft technology (biz logic is all C#)
Performance is critical
I'd like to test as much as possible
My team has only used PHP for web development, but are very experienced with .NET winforms (so either way we have a learning curve). My concern is that some people have expressed concerns about ASP.NET MVC's scalability to large apps. But from what I read webforms have their own problems as well.
Should I be reconsidering webforms, or stick with my gut and use ASP.NET MVC?
Related:
Should I build my next web app in ASP.NET MVC?
https://stackoverflow.com/questions/521388/from-webforms-to-asp-net-mvc
ASP.NET webforms are heavyweight and drop a crapton of stuff on your webpages, both in html/javascript and serialized viewstate. I remember my first ASP.NET website causing the GC to blowed up because of all the short-lived objects being rehydrated from that godawful viewstate. Oh, when I was young and naive (i.e., 2 years ago)... You have to have a very good understanding of webforms to build scalable websites from them. Possible? Definitely. Easy? Not.
ASP.NET MVC is harder to code initially, but is SO much easier to develop than webforms. The hardest things to learn are 1) the conventions aka "magic strings", 2) Html + inline code aka ASP and 3) html forms.
With MVC, you can't get away with the state nightmare that is so common to webforms development, which means that means your webpages are meth-addict slim. It also means you have to code your state a little smarter. The code is also MUCH simpler and scales MUCH better than traditional webforms, imho.
Also, testing with ASP.NET is near impossible, due to the hard-coded and unmockable dependencies baked into the framework. ASP.NET MVC replaced all of these with System.Web.Abstractions members that are mockable wrappers around these badly-designed and untestable objects.
Run, don't walk, to MVC.
For the obvious-impared, if you use a framework that sits ontop of the ASP.NET framework, such as MVC or any other that you wrote or that somebody else wrote, OBVIOUSLY some of these remarks don't apply.
If, on the other hand, you code as early man did against the ASP.NET webforms model (e.g., Response.Write() in Page_Load), my comments apply.
Can you write code that's testable against ASP.NET? Sure. Can you do it without including special testing code you or somebody else wrote? Sure. If you have TypeMock.
ASP.NET WebForms is very much like Winforms and allows for RAD (rapid application development). It's very fast to get something in no-time. Problem with this is testing can be a major pain and if used for anything public facing can mean some major issues with ViewState. WebForms can hold state making things like a wizard a breeze to use.
ASP.NET MVC on the other hand can take a little longer to develop with and requires that devs understand how HTTP works. It's a stateless architecture meaning each request is it's own little world and usually has no knowledge of previous requests. The framework also allows for high testability.
As far as performance goes they're probably the same because ASP.NET MVC is just a framework built on top of the existing ASP.NET architecture. Though for client-side experience I'd say MVC is a bit faster.
As far as scalability I would say they're about the same as far as technical goes. How as for using the API and integrating it MVC would probably be a bit easier.
The website you're using right now to ask this version question is built on ASP.NET MVC and they have 2 web servers and a beefy db server.
ASP.NET MVC is not a problem for Enterprise, but neither is ASP.NET, Silverlight, etc. They are all UI technologies. The majority of your application logic should exist in libraries beneath the UI layer anyway, so pretty much any UI can be used.
We need to use Microsoft technology
Performance is critical
I'd like to test as much as possible
Based on the above, ASP.NET MVC will work. But, you can move the code down below the UI and test. If your algorithms are below the UI, you can tune them without altering the UI. And, if the UI layer is very thin, the perf hit for the UI is negligible.
No. One thing that the ASP.NET MVC has over ASP.NET Web Forms in terms of performance is that it doesn't make use of a control tree. The control tree consumes a lot of server side memory and keeps the garbage collector very busy on pages with many controls. I would argue that you would get superior performance from the ASP.NET MVC. The unit testing aspects of it are a real win to.
The flip side of this is that you can't use all of the handy out of the box controls that you get with ASP.NET Web Forms and you'll probably end up doing more client side JavaScript development so the initial development budget would probably need to be greater if you choose ASP.NET MVC over Web Forms, but you would have a superior solution for the long term.
Stick with your gut. ASP.NET MVC helps facilitate testing because almost the entire API derives from interfaces.
Have used WebForms for years and never liked them. Now use Asp.Net MVC for some years and this is so much better. Certainly woud recommend MVC.
Asp.Net MVC has an excellent architecture and is open source. So if you would identify bottelnecks in the http processing chain you could fix it. Most time you would be able to fix performance issues using one of the many extension points provided by Asp.Net MVC, like Binders as an example.
I would say go with MVC if you need or want its features . If you are building a line-of-business application such as an ERP or CRM system, I would use Webforms; if you are building a portal or community wiki type site I would go with MVC hands down. Ultimately it comes down to preference and what exactly your enterprise application needs to accomplish.
"With MVC, you can't get away with the state nightmare that is so common to webforms development, which means that means your webpages are meth-addict slim"
Upmodded for that quote!
My opinion: use ASP.NET Webforms.
Disable ViewState in the Web.Config.
There is no need to preserve state because everything you really need is in the Request object.
Use Javascript in conjunction with AJAX for data retrieval to render your UI controls client-side.
Create serverside wrappers in the form of control tags for your client-side component renderer.
This is how I've been working for ages now, and it's fast, reliable, testable and organized.
It does take some time to setup a decent framework for this working method, but eventually it will rule.
I rather have no spaghetti code like MVC. Been there with PERL/PHP and classic ASP.
Everything I've read about asp.net MVC says that it is able to serve up more page requests than asp.net webforms.
I have some doubts about its stability and security though. Both of these stem from the fact that it's not even released and even with the RC we saw some changes to the framework. I am sure there will be more changes as time goes on and things are found. It's new so there are not really "best practices" out for it and there is a not a wealth of experience out there detailing the small issues or gotchas that you might run into.
I've been using it and it does result in smaller pages and faster performance. But there are so many things I can do in webforms that I have no idea how to do with mvc because mvc does not promote the use of the webforms controls.
If you're able to use stored procedures then you don't need a big middle-tier like those generated by MVC. All you have to do is pass XML to your stored procs through a simple HTTP handler, get results back from a stored proc, and convert the results to JSON. MVC and other middle-tier stuff only serves to make money for companies that sell IDEs like VS.