As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have a website that primarily renders pages from a database. We also have a user management system in the website, requiring login, profile management, credit card processing, etc. There are some places in the site that have application functionality, like a forum, but most of the site is dynamic content, rendering from a the database. Content is entered with an inhouse CMS that is not tied to the website.
I'm upgrading the website from ASP to .Net 4.5 framework. What is the best option for this new project in VS 2012? An ASP.Net MVC 4 Application (Internet Application) or a new ASP.Net Web Site (Razor v2)?
I'm leaning towards ASP.Net MVC 4 Application (Internet Application, Razor), instead of Web site.
UPDATE: I've actually done a lot of reading on this, whether here in SO, or other sites, and still am not sure which is the best option for migrating to .Net from classic ASP for my specific needs.
Current:
Classic ASP website (100's of pages), public facing.
Most pages are rendered from a database, with template HTML in .asp page, when data populated from database. Could be compared to a WordPress site in function. Content is entered into CMS, and rendered on the website via templates.
Members log in to the site, have profiles, make payments, and more.
Have a forum
All URLs designed for search engines. URL Rewriting in IIS. I need to keep the existing URLs, and have them work with the new .Net site. IMPORTANT.
Client side operations are a must, integrating with jQuery tools, lightbox, etc.
This is not an "application" website, per say. It is a public facing website, like MSNBC or similar, that gets updated frequently (several times per month, if not more).
I'm at a loss for choosing the ideal project type for this migration to .Net. I don't think web forms are a good choice, and MVC 4 appears to be a good choice based on what I've read, but perhaps I can do everything that is necessary with a standard ASP.Net Website (Razor v2) template.
I'd like to get some opinions on which way to go with this, from people that have done it already. Thanks for your help.
I would use .NET MVC 4 . But there is not much online source if you get stuck. But I think you will survive anyway. The only downside is that you need more time to learn the new stuff because it is very different from the old stuff.
If you have enough time, go with the MVC 4. Once you do the project with it, you can do any changes easily in the future.
There are three kinds of websites you can create out of the box (and a number of subtypes). ASP.NET WebForms, ASP.NET Web Pages, and ASP.NET MVC. Which one you choose is as much a matter of personal preference as it is anything else, although certain kinds of sites make certain things easier to do.
In general (and these are not hard and fast rules)
WebForms - This is the way that 90% of the people do it, and there is lots of knowledge and books and information out there. It works, but has a lot of things you have to deal with in terms of creating standard conforming html, testability and maintainability. There are solutions to all these problems, and they're well known, but in general it's considered "old technology" (not as old as classic asp though)
WebPages - This technology is based on the Razor view engine, and treats pages more like classic ASP where you intermix code and html. In general, this allows you to quickly create web sites with functionality behind them, but at the cost of longer term maintainability and testability. As with anything, you could force process to solve these problems, but the framework itself is not really geared towards it.
MVC - This technology is based on the well known and well understood MVC user interface pattern. It focuses on separation of concerns to improve maintainability, testability, and ease of development. It does require a significant departure from traditional ASP.NET development, and a steep learning curve. You have to know HTML, CSS and JavaScript in much more depth than with WebForms.
I use MVC for everything I can, it's just more logical for me. MVC is one of those things that is really confusing until you reach an "ah hah!" moment, then it all snaps into place.
What you choose is entirely up to you. You have to decide HOW you want to develop, and that will guide your decision.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have an web site built in ASP.NET. It is a business website that works with a lot of data.
I had a lot of problems, especially of speed and effectiveness, so I did what I can with ajax, and speed greatly improved.
I wonder if I should switch the web site to ASP.NET MVC?
I don't know ASP.NET MVC very deeply, so I want to know if I should invest in it, the main question is: Is ASP.NET MVC faster and more effective than regular ASP.NET?
I believe that ASP.NET MVC is (if not, already has) becoming the mainstream way to develop websites in using the ASP.NET stack. There is a lot less emphasis on ASP.NET WebForms in the last few years, which hints that MVC is the sensible choice for starting new projects (Note: WebForms is still a popular choice for some devs though, I'm not saying don't use it ever. There's still a place for it.)
Regards migrating existing ASP.NET WebForms apps, I would be a little cautious. Don't switch to another technology unless you have a very, very good reason for doing so. Depending of factors such as the amount of code, the design, it could take a lot of effort to convert an ASP.NET WebForms project to ASP.NET MVC.
In your situation you mention performance issues, which made you consider moving to ASP.NET MVC. I would look more into why your site is not performing as you would like. Use a profiler to measure which code paths are taking the longest ot execute. There are plenty of sites built using ASP.NET WebForms which perform to high-scale, so I would not make the mistake of moving to another technology in order to solve a performance problem.
It depends on where your current issues are.
Should you learn MVC - definitely.
Should you write new applications in MVC - sure.
Should you migrate old applications - depends.
What's the architecture of the current application?
How much time/resources do you have to allocate to a rewrite vs fire-fighting the existing app?
Is there a clear data or middle tier or is the data access built into each page code behind? Many applications are written so that the front-end can be swapped easily or called from other applications (eg via an API) but many webforms applications (not all) are written without these considerations and so it wouldn't be a swap out but a complete rewrite of the application.
What are the current issues other than "it's a bit slow"? For example I've seen an app that loaded the entire data model into memory for each page - simply changing the front-end would make no difference in this case as the cause of slowness was the data loading. Changing the architecture to load only what was needed significantly increased the speed.
The improvements you can get from using MVC aren't necessarily the business level ones you might expect. There are plenty of sites that go into this in more details, here's some to get you going:
MVC generates (much) cleaner HTML in the output - so pages are easier to develop/maintain and easier for developing UI interactions in javascript.
MVC has a much improved pipeline which can be hooked into, eg for adding action filters.
IoC/DI is hugely easier in MVC
Separates the model/controller code from the view html
Your application users won't care about any of these.
I have the same situation with one of my clients and after learning the MEAN stack and working with another company who made the transition to Nancy. I would recommend doing a REST API with Nancy and a pure front end with Angular or another Javascript front end. This will allow much faster response and flexibility down the road. Plus it will give you more flexibilty if you ever want to expose your API to other apps.
I tried to move from Web Forms to MVC and it was not very easy for me at the time.
You can use Asp.net Web Forms, with more ajax and less post backs and less view state usage if you do not want to move to asp.net mvc.
Asp.net MVC on other hand is very good with light wight pages and capabilities to blend in with client side ajax based solutions. And its architecture supports scale ability.
I think you should definitely take the time to learn MVC, as it is becoming a more marketable skill and future projects are more likely to call for it.
With respect to being faster and more effective, it is somewhat. First off, WebForms have a lot of overhead in order to have this windows-forms-like behavior (which, frankly, has never been a perfect fit for web pages). Second, MVC tends to render HTML that is much cleaner without the view state or long IDs. So those two items can make it faster. (Of course, if you are having speed issues you also need to look hard at your host server.)
With respect to rewriting your current project to use MVC, that's a more difficult question that only you can answer. WebForms still work and will probably be supported by Visual Studio for many years to come. Depending on your project, rewriting it can be a costly task. So you'll need to decide if it's worth it. That said, I hope to rewrite all my webforms websites using MVC as time allows, although part of the reason is just to update the look and make them more responsive to mobile devices.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am in the process of architecting an application. It will be a large, enterprise class web application. Thousands of users could upload files, search large number of blog entries with chat functionality and such. It will also have mobile interface. It should be highly testable, scalable and flexible.
I have narrowed it down to three environments: pure play ASP.NET, pure play DotNetNuke (DNN) and a combination of ASP.NET and DNN. To keep this very brief, here are some 'for' and 'against' on each of the options:
ASP.NET:
for: highly scalable, supports patterns like MVC, testable, consistent architecture.
against: long development time.
DotNetNuke:
for: short development time, large number of existing functional modules and skins.
against: architecture is sealed, can't support MVC, unit testing is difficult, inconsistent modules/skins, potential upgrade issues, user experience is inconsistent due to disparate modules from different vendors, poor documentation.
So, the questions are: what do you think? Has anyone switched from DNN to ASP.NET (and, vice versa)? Have you objectively evaluated these two and what did you choose?
Highly appreciate your help. Thanks.
henry.
DNN is ASP.NET, just with a lot of the work done for you.
Also, please remember that just because raw ASP.NET has the potential to be more scalable, doesn't mean that you are actually going to built it to be more scalable. Or that you will built it well in the first place.
It comes down to a trade off between control and resouces/talent. If you have many very talented developers (like, top-10% talent), a lot of time, clearly defined requirements for your site, and consumers who will be patient while you build out the infrastruture, by all means go with raw ASP.NET.
However, if you need to build it quickly and need to be flexible, or you have limited development resources, you might have to sacrifice some of that control and unit testing and potential performance (again, the "potential" part is key here).
Based on what you are looking for, I'd recommend you go with a platform like DNN, or a million other ones line SiteFinity or Umbraco or Orchard or something like that (some of them like Umbraco give you MVC too). It gives you a lot of the infrastructure and plumbing common among a lot of sites, probably done better than you are going to do it, so that you can focus your resources on the truly unique aspects of your application.
Just stay away from SharePoint. It's evil.
I've built raw ASP.NET sites for really customized applications, which was good because I didn't need a lot of plumbing and wanted really unique funcitonality through the site. But then I've built social networking sites with DNN, which worked well because it had packaged components for blogs and forums and chat and all that stuff, plus allowed for easy skinning. I designed another application for a customer that they wanted to have a lot of custom functionality, but they also wanted to updated a lot of content and internatalized it, so we used a Umbraco for that. And right now I have a ASP.NET app that works great, but I want to add in some social features, so I'm going plug in a Umbraco or DNN site that integrates with it to host the more common social components.
I would definitely recommend DNN based on your very limited list of needed features. You can always build a custom module to meet your exact needs or modify an existing open source module as needed. You can use the MVP approach in your module development to improve the testability.
Have you considered the Umbraco CMS? It is built on .Net (v5 is MVC3). It is open source and a very robust and well supported application. It has been used for the asp.net site for example.
It has a very short development time, many modules, extremely flexible and I find it very easy to extend. For example, I rolled my own workflow, event driven publishing and have created multiple custom administration sections for managing bespoke functionality external to Umbraco.
You can use XSLT, Usercontrols or Razor to create template modules.
It has a fantastic community too.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
The website needs to be equipped with a content management system and should provide for social media integration and localization.
What are the pros and cons of each technology platform and when should we opt for sharepoint?
This isn't really a question that can be completely answered on an Internet forum. First, it's a given that pretty much any web site can be built with either; secondly, building most websites with ASP.NET is also mostly a known quantity - ASP.NET is generally linear, in that developing any feature with it is simple function of developer time.
So the real question is SharePoint - and would you save developer time by leveraging it's power, or spend more time working around it? Only an architect in your organization can fully answer this by:
Understanding the requirements;
Turning those requirements into questions;
Standing up a test instance of SharePoint and spend some proof-of-concept time answering the questions.
SharePoint does indeed offer great capabilities that would take hundreds or thounsands of developer hours to deliver from scratch, and it can be enriched with very small amounts of custom development - if you can align your requirements to its featureset. If not, you'll spend 3.5 years and 25,000 developer hours bending it to your needs (not that I have any experience doing such a thing :D)
If you need content management capabilities SharePoint actually does not require custom code. Moss 2007 and SharePoint Server 2010 come with web content management out of the box. It 'only' requires you to customize the site to give the look and feel your customer wants. Social media definitely requires custom code. A good starting point might be the community kit on codeplex.
If you do not need any of the functions that SharePoint delivers out-of-box - fully or partly - you will be better off with a ASP.NET site. It will mostly likely be faster in development. But as soon as you can leverage some of the SharePoint features it will save you a lot of time. Some of the time saved you will surely spend on weird SharePoint issues and getting to know the product.
Still developing SharePoint is always developing ASP.NET in the end as it is an extension of ASP.NET. So you can do all the stuff such as building web controls, ASCX user controls and web parts in SharePoint as well and at the same time take advantage of the SharePoint deployment mechanism and farm setup that scales well.
Simple, For most of companies, the internal site better be using SharePoint, while external site based on ASP.NET.
For internal site: SharePoint basically offers most of the fundamental functionality that most of companies' internal sites require, be it content management, workflow, or permission. It is not a good idea to develop those stuff by yourself, unless your requirements are very special.
For external site: SharePoint is too big and too complex to be an external site, especially for SharePoint 2007. Maybe it is great to seamlessly integrate internal site and external with SharePoint, but considering its lousy compatibility with other browsers as well as clumsy code, it is far better to develop a site by yourself than using SharePoint, then daunted by maintaining lot of codes, writing additional code to improve its compatibility.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I found these questions, but a couple of them were a little old:
https://stackoverflow.com/questions/191556/should-i-pursue-asp-net-webforms-or-asp-net-mvc
Do you think ASP.NET MVC will compete with ASP.NET Webforms?
ASP.NET MVC > ASP.NET WebForms, Why?
I do not believe these are duplicates and might be old enough that new light can be shed. If not please close this.
I know that no one framework or language is necessarily the only tool for every job. But, do you see MVC eclipsing webforms or webforms going lower on the priority list for Microsoft? They will have to keep webforms for a long time because so many have invested in it, but they don't have to keep adding new functionality for it.
I don't know if this is a good example, but it reminds me of web parts. I never saw much improvement in it from Microsoft. It works and I thought it was great until I started to really try and get a lot out of it. Then from what I could see it just wasn't being pursued by Microsoft that much, though it stayed in Visual Studio. Maybe that's a bad example; just what I remembered.
EDIT: Also, if anyone has any statements from Microsoft on this subject it is appreciated. No offense to anyone. I was only hoping for something official.
this Microsoft answer:
ASP.NET MVC provides a framework that
enables you to easily implement the
model-view-controller (MVC) pattern
for Web applications. This pattern
lets you separate applications into
loosely coupled, pluggable components
for application design, processing
logic, and display.
ASP.NET MVC is not a replacement for
Webforms. It provides an alternative
choice when designing a Web
application. Using ASP.NET MVC offers
the following advantages:
• It enables you to achieve and
maintain a clear separation of
concerns
• It facilitates test driven
development (TDD)
• It provides more control over the
URLs you publish in the application
and over the HTML that is emitted by
the application
They both have different strengths.
MVC is great for public internet sites where precise control of the html and page lifecycle is important.
Webforms are great for corporate lan intranet sites, where development speed is critical, upstream bandwidth to the web server is plentiful, but memory on the server is more constrained.
Honestly, more asp.net programmers are probably doing the latter than the former.
WebForms are not going away. Microsoft gave it's developers a way to choose between traditional asp.net programming and the popular MVC way of programming. It's not competing against webforms it's just another choice for developers to use. Very Smart move from Microsoft to keep a hold of it's developer base.
I think ASP.NET MVC allows building much more maintainable applications. It also allows for automated testing of a very large part of the code.
If a website is reasonable in size and/or is going to have a reasonable life span then MVC plays a very good role.
I understand the argument of SEO for public sites, but I think the benefits of MVC make it excellent candidate for even intranet applications. Perhaps with some good collection user controls i.e helper methods, MVC can start dominating the field.
I believe rather developers' focus of interest will shift towards MVC.
As for the practical use scenarios, WebForms will likely continue to be used for applications and rather "closed" sites, while MVC will be the preferred choice for those sites facing public (and search engines, yes).
Just like everything else, I think further development will depend on how popular it becomes. The more people use it, the more Microsoft will likely invest in it's future.
It already seems to be quite popular, and judging from the popularity of similar frameworks in other languages (e.g. struts or rails) I think it'll continue to gain popularity.
See my response last time:
Is ASP.NET MVC swept under the rug to make room for MVC?
I believe ASP.NET MVC is not here to replace WebForms.
Instead it will give an alternative for ASP.NET developers who want to develop with separation of logic and view in mind, as well as performance and ease.
The introduction of .Net was bad for developers that had mastered VbScript, ASP Classic and being the few elite that could actually debug in Visual InterDev.
MVC is bad for those continuing on the path of WebForms only.
Pretty much by this time you should be able to recognize the hand writting on the walls as to whats coming down the pike.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm starting a new web project and I am considering two presentation frameworks. I am thinking either about ASP.NET MVC or Silverlight. I would tend toward Silverlight since I'm quite experienced .NET developer while I have just a basic knowledge of ASP.NET controls.
It is mainly going to be an iternal
product so browsers are not an issue.
You still have not written a proper description about the nature of your application. It is difficult to assess which technology is a good fit without first knowing well enough the domain the application is being applied to, and the problems it is designed to solve.
In general, Microsoft is positioning these array of presentation technologies on the "Reach vs Rich" continuum. You have "plain old" HTML and Javascript on one end, acceptable by the most number of client machines out there, and the ultimate full-blown WPF on the other side where limited number of machines can handle. You did mention this to be an internal app, so WPF via XBAP or ClickOnce are also possible.
So the scale would align this way: (reach) ASP.NET, AJAX, Silverlight, WPF (rich).
So the question is just how rich you want/need it to be for the users until it hurts the deployment base? Frankly if all you fetch are forms and tabular data and statistics then regular ASP.NET web forms are just fine. If you want on-the-fly resizable graphs and client-side interactive with back-end WCF web services Silverlight can do that. If you want even more powerful graphical rendering than WPF via the remote deployment options is your bet.
Silverlight 3 with RIA seems to be very powerful. I hadn't programmed for 6 years after working on VB6. I about a months time, here I am developing a web applicaton that uses SL3, WCF and entity framework and I feel very comfortable.
The silverlight forum and stackoverflow ofcourse are very active and for some of the problems that i've had had, I have been able to get a solution easily.
The one thing I'm not sure of yet is performance.
Both personally and professionally, I write C# daily for Windows forms apps and Windows services. Even after years of this, I find it FAR faster to whip out a web app with PHP or Python than to do it with .NET. Maybe things have changed with Silverlight, but to me the learning curve on ASP.NET is ridiculous compared to the payback.
Edit: The above was written a year or so before I tried ASP.NET MVC. I find ASP.NET MVC wonderfully intuitive and clean.
Don't forget Silverlight is going to require a plug-in to use, and to my knowledge it has not been "natively" added to IE, let alone the rest of the browsers. So there could be tons of maintenance/support issues with that alone. PDF files are considered "ubiquitous" by now, but you still run into a user or two that doesn't have Adobe Reader on their computer and it often occurs at a bad time and then you're scurrying around to get an installer.
At a fundamental level, this is what has kept me from doing Silverlight for my web apps. I think the technology behind it is good, but considering nowadays you could get equal visibility/functionality with a nice Webforms/MVC/AJAX/jQuery combination (mix and match to your liking), I'd say stick with ASP.NET.
IMO you may be better off with ASP.Net. While you would have a slight learning curve, you'd be developing on a proven, reliable, scalable model rather than something thats in beta and will likely change before RTM.
Also, with AJAX these days its possible to get a pretty slick user experience out of ASP.Net.
I would recommend ASP.NET, no additional download is needed.
I used Silverlight but a lot of companies are not allowing users to install anything also home users are not happy to install browser plugins, Silverlight is not so known as Flash player.
For beginners and advanced programmers you can find video tutorials at.
http://www.asp.net/mvc
It's hard to recommend one over the other without knowing what your application is. Whatever you do decide, make sure you keep your target audience in mind; not everyone is going to have Silverlight installed on their computers.
Personally, unless I was designing an incredibly interactive and beautiful web app, I would go with ASP.NET (with or without the MVC framework) if only for the fact that there is a ton of reference material for it while Silverlight is still relatively new territory.
It is mainly going to be an iternal product so browsers are not an issue. It's more about the price of development. Is it easier to learn Silverlight model or ASP.NET model? I expect that Silverlight is based on WebServices and so it might clearly divide my application code into a business logic (service) and presentation (silverlight application).
Given your background in .NET but limited Asp .net experience... I assume you are more of a service/client guy. Which will mean your javascript is probably just as limited... If this is the case, I'd go with Silverlight. It will ease you into WPF, which you may be likely to use in the future.
But more importantly working with Silverlight 2.0 feels more like building a sandboxed desktop application. More than a web application. You will be more at home with Silverlight if your prior experience is with client apps.
If you want to break into building web sites/applications go with ASP .NET MVC.
Either way knowledge of the typical ASP .NET controls will not go far, since they are for WebForms.
I would say - unless you need flash-like animation and interaction capabilities - go for ASP.NET. It's simpler to program against and doesn't require extra downloads for the users.
I think Silverlight is only required when you want to create applications like Flash. These applications are combined into a single executable which are downloaded once on the client machine. They can communicate with the server if they need any data or any functionality which resides on the server. The end user needs to install the Silverlight environment add-on to help run these applications.
Whereas if you create an asp.net application, its code resides and executes on the server itself and hence a simple internet browser can execute it. But the downside is that for user-interactive applications, there need to be separate calls made between the server and client machine when the code requires.