I am reasonably familiar with C# desktop development and am very familiar with Rails, so ASP.NET MVC makes sense to me. However, I have a more lightweight site that I want to build in a manner more akin to dropping a bunch of .php files into a hierarchy of directories and having them be served up as just HTML files run through a pre-processor. (A full MVC stack and architecture seems like overkill for what is basically a brochure site.)
I believe it is possible to do this in ASP.NET (I remember the single .aspx pages approach from back in the day), but I'm not sure what this programming model is called in order to search for info on it--I can only find references to MVC and "web forms" in newer documentation.
I also would like to use pieces that are more popularly used in MVC, but in this more simple page-based model. For example, I would like to use Razor templates (with layouts and partials) and to access a single Model object that is shared across a number of templates.
I would appreciate any advice, or info on how to find documentation on using ASP.NET in this way.
The ASP.NET Web Pages framework supports web applications built using the Web Site project type* as well as Razor layouts and partials. It does not support strongly type models in the same way as MVC. However. that doesn't prevent you from taking a strongly typed approach to Web Pages development. The mechanism for passing data to partials is via the dynamic Page property (similar to ViewBag) which requires casting to get Intellisense support. Web Pages also lacks any kind of Model Binding support.
*This is the ASP.NET project type that does not require pre-compilation before deployment (as opposed to the Web Application project type). Web Forms apps can be built using either project type, but ASP.NET MVC apps can only be built using the Web Applications project type.
Related
I'm looking at the differences between a Web Site and a Web Application on MSDN, and am drawn to the features of a Web Site because I am tasked with devising an architecture in which customers can heavily customize the application we deliver. It seems this feature of web sites would be useful:
You want to be able to update individual files in production by just
copying new versions to the production server, or by editing the files
directly on the production server.
However, I'm also drawn to the MVC architecture because it has built in features for minifying scripts that are delivered to the client. I also kind of like the idea of breaking up the architecture into clean pieces since this is a very large data model we have.
But from what I can tell, these sets of features appear to be mutually exclusive. Is that true? I can't readily figure out how to create an MVC application in which custom views could be dropped in as pure source files, and be able to run, nor can I figure out how to take advantage of any MVC framework when creating a "Web Site" project. Am I missing something or do I have to pick my poison?
Take a look at ASP.NET templates in VS2013. You can create an app with both MVC and WebForms. This will probably give you a good combination of what you need. By default, view files are not compiled, so you'll always be able to publish new files without doing a full push if you want. In fact, VS2012 even allows you to publish select files or folders.
The choice between web site and web app to be is very simple. If you are creating a mostly static app, choose "web site". If you are creating an app that has even a decent amount of dynamic capabilities, choose "web app". Web Sites are not really designed to be dynamic, so the more dynamic you do in that setting, the more of a headache it will be to properly maintain it as the architecture just isn't where it would need to be.
What I would suggest is to spin both of them up and try out some scenarios that you are interested and see what works and what doesn't. Really think about how users will actually want to customize the app. Will they want to copy and paste files to production or would they rather request features and have them built properly? Or maybe they want to work with a workflow instead?
So make realistic business requirements, prototype and then decide. But based on what I'm hearing you want a WebApp and probably one that does MVC and WebForms.
Now everything ONE ASP.Net. You will be creating a WebForm, MVC, Webpages using ASP.Net platform.
Check this video about new features in VS 2013
Not sure you can create website in ASP.Net 4.5.
From my experience, I would go with WebApplication based project, where managing namespace and other stuffs are easy. In website its hard to get the standard name for the classes(randome) generated.
Go with MVC web application.
When creating a new web project in ASP.NET are you better off to use the "ASP.NET empty web application" or the "asp.net web forms application"
I would recommend against even bothering with ASP.Net Web Forms. It was an interesting idea that proved to be unweildy in practical applications. The entire web development industry is moving towards some kind of MVC framework or another whether you're using PHP, Ruby or ASP.Net so you're best off using that.
Of course there are still a lot of ASP.Net Web Forms applications out there and they're likely to exist for some time into the future so there is some benefit to learning the technology but I would avoid it for any new projects.
As per your question if you should use the empty project or not it doesn't really make a difference. If you're just starting out the populated project can give you a basic idea of how the structure works but if you're comfortable enough building it from scratch then go with the empty project.
It depends on what you want to do.
Generally speaking, there are three kinds of ASP.NET application project:
Web Forms - what ASP.NET was originally back in 2001. Its use is discouraged in modern and greenfield applications because it is built-around outdated ideas about how web applications should work.
MVC - The new hotness. Try to use this. StackOverflow is built using this.
Everything else - too many to list, but this generally requires you create an empty project and do everything from scratch using IHttpHandler.
If you're new to ASP.NET I strongly recommend avoiding the two project types you listed as they're both for Web Forms; consider using the "ASP.NET MVC Application" options instead - if you're using VS2008 then you need to download and install the ASP.NET MVC 2 add-on. VS2010 and later come with the MVC templates preinstalled.
You might want to use the Empty Web Application project template if you want to work from scratch using IHttpHandler, but you sound new to this, so I recommend avoiding it.
I'm on the point of starting a medium scale web application and I'm considering developing using ASP.NET Razor syntax Web Pages framework (not MVC). But as I've seen many people consider "Web Pages" to be tailored towards beginners.
I'm developing professional large scale web applications in ASP.NET Web Forms for several years now, but I've always inclined towards clean html/javascript code more than server side controls therefore I find Razor syntax very much appealing. I'm using Visual Studio and not considering web pages for helpers functions or other beginner eye candy features.
Having this in mind what are your opinions on scalability, speed, long term development on this approach?
In terms of performance WebPages is asp.net and gets compliled so performance should be similar to WebForms and MVC.
I'd say that any site that could be built using ClassicASP, PHP or WebForms (without using server controls) can be built just as well using WebPages.
I prefer WebPages over WebForms and MVC for my sites. You get full control over the HTML, don't need to worry about concepts like the page lifecycle and postsbacks unlike WebForms. On the other side you get a lightweight, simple framework where you don't need to use VS.net, solutions files, project files and 3+ files to serve up a single page and you don't need to compile the entire solution before deploying unlike MVC.
But what you use I think depends mostly on your detailed requirements and skillset.
But as I've seen many people consider "Web Pages" to be tailored towards beginners.
Go for the ASP.NET MVC 3 and the Razor view engine then. It provides you with the WebPages syntax coupled with the full power of the MVC pattern built on top of an established platform such as ASP.NET in terms of scalability and long term development. You can't dream for better as far as the Microsoft stack is concerned.
We have a web site built as an 'ASP.NET Website' type project, rather than the 'ASP.NET Web Application' type.
Aside from the obvious debugging advantages that the app type offers and access to the designer files for each page:
What, if anything, can be gained by switching from website project type to app?
Are there performance losses with one over the other?
How much work is involved in switching an existing (dev) site from website to app? Is it as simple as creating another site as app type and adding these existing aspx files and libraries to it?
This question (How To Convert ASP.NET Website to ASP.NET Web Application) seems to cover the steps.
What are the risks (if any?)
How much work should we plan on?
Are there differences in how HTTP Application deals with requests or how handlers work between the two types?
Anything we forgot to think of?
http://msdn.microsoft.com/en-us/library/aa730880%28VS.80%29.aspx#wapp_topic5
That describes some of the features and advantages/disadvantages between the two.
The main reason to use the web project versus the web site is that the web site is dynamically compiled which tends to incur a performance hit whereas the web project is precompiled. You should gain performance moving to the web project method. You also gain control over the naming of your final compiled assemblies.
The amount of work really depends on how many pages are in your old site.
I don't think the .NET framework handles code differently in the web site versus the web project. It's really the configuration of the file structure, the lack of a central project file, and the method of compilation that ends up being different between the two.
I will apprecaite your help in this topic.
I need to build a site with friendly urls using url rewriting in order to improve SEO positioning.
I've been searching torought web and finally pointing to this two main options :
asp .NET with isapi extension
asp .NET mvc
however, I got no experience on both items so I need you to help me to kwow further about this two technologies and to take the right decision for my needs.
Thanks
There are much bigger concerns than just URL setup when making this choice. You're talking about two completely different architectures for building your web pages.
You should make the decision on how you want to build your application, what skillsets you have available in your developers, etc. Both approaches will be able to handle the URLs that you need to generate for SEO considerations.
For public facing websites, I would personally choose ASP.Net MVC, because I find the development cycle shorter, more productive, more flexible and more maintainable than an ASP.Net webforms application.
Assuming you have a host/server that can run ASP.NET MVC (i.e. one that has the .NET Framework 3.5 Service Pack 1 installed on it), you can use the Routing Engine (System.Web.Routing) from ASP.NET MVC in a web forms environment, Phil Haack has a good updated walkthough at "Using Routing With WebForms".
There's also "How to: Use Routing with Web Forms" on MSDN.
Unlike an ISAPI filter, this enables you to use the routing engine to generate your internal links as well as responding to well formed links from outside.
I agree with womp. But there is one advantage i see in Asp.Net webforms that Asp.Net Mvc doesn't have: Rich Client Iteraction controls. Everything in Mvc in View layer is simple and functionality need to be build from scratch.
alexserver - at the same time of course, the fit between mvc and jquery is an overwhelming reason to abandon the rich clinet controls. that way, you can literally get your designer and/or a jquery UI expert to work on the view portions in isolation whilst you craft the model and controllers.