I'm just starting to convert an existing ASP.NET Web Forms website to ASP.NET MVC. However, MVC seems excessive for some pages. ASP.NET Web Pages seems like a better fit for simple pages where the benefit of MVC is unclear.
If I use ASP.NET Web Pages for some pages and MVC for the rest, what difficulties will I likely encounter that would not occur if MVC was used for every page?
Here is one difficulty I am already aware of: Web Pages and MVC cannot share _Layout.cshtml.
EDIT
The content above was heavily edited to clarify the intent of the question.
I did a little research into this and now fully understand the scope of your question. Sorry, it was my mistake for thinking you mean Web Forms and not the relatively new Web Pages.
Any answer anyone gives here will be pretty subjective, but my take on this is to go ahead and stick to the MVC method instead of mixed modes. It appears that Web Pages is a razor based HTML file without a controller/action associated with it. If that is truly the only major difference / reason for your question, then it seems the extra three lines of code it would take to make it MVC...
public ActionResult StaticFile(){
return View();
}
actually will make it a) easier to add dynamic data to in the future, b) more directly ties into routing (no special routes for static for example) and c) easier to interact with the server-side if you have to do any kind of authentication, session tracking, etc, etc. Anyways, my 2 cents. Go the way that works, but keep in mind the trouble/frustration of future modifications as you go forth with your site. I post this opinion with the admission of never having used Web Pages, just a few hours of reading about them.
The biggest pain is the maintenance of a Master Page and a __Layout view. That being said I am with Tommy - why not just make these static pages html files and not aspx pages.
I decided to abandon ASP.NET Web Pages and use MVC exclusively on my website. The primary reason was because of the duplication of effort for things that could not be shared between Web Pages and MVC. Here are some things I learned.
Web Pages and MVC could not share _Layout pages. I was able to work around this by moving shared content into sub-layout files that the Web Page _Layout and MVC _Layout files could share.
Forms authentication was no problem.
I was not able to figure out how to implement MvcSiteMapProvider in the Web Pages for breadcrumb functionality. (See this question.)
The MvcSiteMapProvider difficulty made me realize that it was just a matter of time until I found something else that could not be easily shared. Therefore it seems smarter to stay with MVC rather than taking a hybrid approach.
Related
I am writing a simple web page for our existing web site that will only be used by the web site admin to delete all images from a certain directory on the server. He would browse to this page from his web browser (not to be consumed by any external services as of right now). I was thinking of creating another ASPX page (obviously not linked from or to anywhere) that implemented this. Is this considered a RESTful API? If not, what would be, and would it be a more elegant solution than what I'm proposing?
I realize this is an extremely simplistic example, but I'm trying to understand what RESTful really means and if it would benefit our existing infrastructure in any meaningful way, so that's kind of the purpose of this question.
Our website is written entirely in ASP.NET 2.0 WebForms.
It depends on your URL structure. a classic REST API call would be to, say:
/images/delete
You would then send a Post as DELETE or just GET or POST to this to do what you need. That's more the RESTful way. REST isn't so much what you are doing with the method as the structure of that method. I hope that makes sense :).
I am working on a mobile site that uses .aspx for the pages; however, I am transferring information from older .asp pages. These .asp pages are reading database connections, and I am not clear how to convert these into .aspx pages without running into config errors that are unclear to me in fixing.
Is it bad practice to mix .asp and .aspx pages in a site? If not, how can I learn to better understand the conversion differences from .asp database connections to .aspx? This is the only obstacle I have going on at the moment with this site, and I would love to find a solution soon as I've been stuck here for a while.
The site works, but I would like to be consistent with the .aspx set up in pages. I appreciate any help you may have to offer, thank you.
You can absolutely mix ASP pages with ASP.NET pages. I've done it for internal sites where we didn't have time to redesign, but needed to add some functionality. Note that you can't share session state between the two types of pages (I worked around this using cookies) but the two pages can live together in the same web site without an issue.
Often ASP pages will have database connections kept in the global.asa file or perhaps in an include file, or even right within the asp pages themselves. It would be helpful as you migrate functionality to have all those connections in one logical place.
There is no straight conversion to ASP.NET from ASP, and if you don't have much experience yet with ASP.NET it would be worthwhile to explore some samples / tutorials to get an understanding of how an ASP.NET Web site works. There are lots of options for how you connect to your database. Have a look at www.asp.net to learn about them.
You can have the two running together. It's not necessarily a bad practice to mix the two, but here can be some technical things that you'll have to work out. Since it sounds like you're trying to convert a classic ASP site to ASP.NET, if there are not too many pages, I'd probably try to figure out the conversion issues so that all of your pages are running on ASP.NET.
Otherwise if you do want to run ASP and ASP.NET side by side, if your website has session state or authentication and you need that shared by both asp and asp.net pages, then you need to ensure that you have a strategy to handle that kind of stuff. This thread details session management issues to consider when running ASP with ASP.NET, for example: Classic ASP and ASP.NET Integration.
I am trying to create a static HTML page which has a <form> which posts to a 3rd-party ASP.NET website.
Is this possible when the target website uses ASP.NET webforms?
This is absolutely possible. You can issue a POST to any website, anywhere. (Keep this in mind when you're designing an application that accepts POSTs from a web merchant such as PayPal ;-) make sure you know where the POST is coming from.)
Whether or not the website will accept your request, of course, is up to however the server-side code was programmed. If you're POSTing to an ASP.NET WebForms app and the app wasn't designed to accept third-party POSTs, then you're going to have a hard time making your POST parameters look like they came fro ma WebForms page. For example, the website will be looking for the encrypted viewstate, among other things.
You could use firebug or some other tool to sniff the POST data from the webforms app, and then replicate that data in your static HTML page .... it might work.
Do you have any programming control over the ASP.NET Webforms app at all?
check out this question:
How to POST Data to another web application (cross domain)
Let me know, if you need help with my implementation.
I have been reading on MVC and I created some db-driven pet projects with it and I am very pleased with the shift from WebForms.
However, I have a bit of a limitation that holds me back with WebForms and I was wondering if you could help me with it.
I work for a Web CMS company as a Consultant, therefore all websites (public sites, intranets, extranets, you name it) are based on the CMS software from my company (which should remain nameless).
One of the features that the sales guys like to pitch about our software is its "friendly" urls. Baiscally all data is stored and structured within the CMS like a file system. Then when you point your browser to http://mywebsite.com/about the CMS will return the contents from the item stored under the root with the name "about".
Each item also has a (interchangeable) template registration which is the physical location of the file that is going to display the contents of it (an .aspx page). Just like the "Views" on MVC.
To handle the friendly URLs I have to add a HTTP Handler as follows:
<add verb="*" path="*"
type="Cms.ASPDelivery.HttpRequestHandlerFactory, CmsDelivery" />
That will take care of the friendly URLs and will do the mapping between contents and views.
In an architectural way you could see that just like MVC. The data is stored in the CMS, the presentation is independent of the data, and the handler will be the Controller.
But when it comes down to coding in itself, it is the same old Webforms spagetti.
So, my question is: Do you see any way that I could use both MVC and my CMS' Http Handler?
It depends on the concrete Implementation of the HttpHandler but in most cases it is possible. You have to add the MVC UrlRoutingModule and setup the MVC. I use MVC in a CMS environment with friendly url-s. The CMS is called EPiServer and from what you described it has pretty much the same functionality. I use ASP.NET MVC for the template pages. The path to the physical pages is actually handled by controllers' actions. It works fine and with some tweaking I can say that it is a lot better than WebFroms especially if you develop custom web applications.
Is it a good design to have multiple masterpages in an application.
I am building a website using Asp.net MVC with different type of users like, admin, employee, general user, etc
And every user once logged in have different type of controls on the website, so I was planning to use different master page for each user.
Yes it is a good design, and make sure to layer them appropriately. Master pages specific to controllers should be placed them in the appropriate view folder.
If it makes life easier for you and your users, than I see no reason why not.
I don't know how about Asp.net MVC, but in Asp.net master pages inheritance is possible. You may create site.master, and admin.master, employee.master, etc that all inherit from site.master.
But take care of master pages inheritance. In my project, it seems that sometimes paths may point to wrong locations. I don't know whether it is my mistake or is a bug.