I've built several database driven web sites with ASP and I'm trying to migrate the basic functionality to an ASP.NET architecture.
I want to have each link in my navigation tree correspond to a different function that will step a user through various requests and provide sequential database driven responses and possible follow-up questions. I typically do this in ASP by using the query string to execute different parts of the code in an SSI file. Each link in my navigation tree basically calls a different SSI file.
In ASP.NET I think I have a pretty good handle on web form basics, data binding, site navigation tools and master pages, but I'm having trouble with the overall design picture.
Do I want to have each link redirecting the user to different pages? My understanding is that ASP.NET is much better at maintaining state information and so I shouldn't have to rely on the query string to keep passing values to an SSI file to do sequential parts of each task.
Should I be using BLL and DAL to do this and/or stored procedures and managed code? Or could I do this sort of thing more simply with ASP.NET web pages, as opposed to web forms?
Feedback that would include a reference article and/or web example would be greatly appreciated. Thanks!
You don't necessarily have to abandon your whole way of thinking and take up ASP.NET Web Forms.
I've been making sites with ASP.NET Web Forms since it came out in 2001. But I think ASP.NET MVC would be an easier transition for you. I mean, some things are more difficult in MVC than in Web Forms. But on the whole, MVC will promote more web friendly practices and it's what I prefer now.
For example, the whole idea of postbacks and viewstate in Web Forms certainly makes a lot of things easier. But they also have a problem of hurting SEO and breaking the back button. MVC doesn't rely on any of this and it's easier to refine the user experience with the way form posts, redirects, and URLs are handled.
I wrote an article awhile back comparing MVC vs Web Forms...
http://swortham.blogspot.com/2009/10/when-to-use-aspnet-web-forms-and-when.html
Based on what I'm seeing, it looks like you've got wizard-style navigation across multiple ASP pages, and you want to have wizard-style navigation in an ASP.NET (WebForms not MVC) site.
If I'm misunderstanding this, I'll gladly delete this answer.
I'd recommend the Wizard control, (Video demos available all over the place) which will provide such an interface in one page, reducing a lot of the complexity. there's no need to keep track of variables across pages - it's all in one page, and therefore always accessible.
Wizard pages do tend to have a LOT of code and markup, but the trade-off is that all of the wizard functionality is in one pace, not scattered across files, and it's inherently obvious what's happening at each step. With the multiple-file approach, a maintenance developer needs to trace which page posts to which page and spend more time understanding the design.
The article on MVC vs Web Forms was quite interesting, although after looking at a few training videos I got the impression that the coding is quite a bit different from ASP. (Most of the examples I also see involve C#, although I have seen a few with VB, which is preferred since I'm already learning a lot of new things in a short time.) Also, I wonder if MVC will let me use the validation tools, which will be quite necessary in a different aspect of this project that involves several different and quite long forms. Given that I've invested a fair amount of time in learning about ASP.NET, I'm wondering if I should just go the extra mile (or two) and learn how to create business objects (BLL) and a data layer (DAL).
Related
Firstly, I have only recently tried my hand at building with razor in cshtml using Webmatrix and I found it much less time consuming than building aspx web forms. Having gotten used to it, I can now do all the things I used to do inside my aspx projects much quicker and with much less code...
Now, I've spent today looking around google etc at companies using cshtml, what they're using it for etc, but I can't find a large range of examples out there. Maybe I was just looking in the wrong place, rendering this question title incorrect, but I just had a feeling that there is a reason why companies are still using aspx over cshtml.
I'm about to start a project next month for a big client and I can't decide whether to take the step of building it this way (they need a custom blog, login area etc). Any thoughts? The only other stack thread I found of any use with regards to a debate was: Razor/CSHTML - Any Benefit over what we have?
Thanks,
Adam
A lot of it has to do with ASP (classic) has been around a lot longer and (depending the project size) a migration can incur too much cost.
There's also considerations like:
What does the current web staff know (what are they fluent in?)
What libraries (proprietary or otherwise) are already dependent on ASP (including custom controls).
How much of an SEO hit are you going to take converting (some sites can mimic classic aspx page suffixes by just changing the way the routes behaving but are in-fact using cshtml).
There isn't a compelling reason for experienced ASP.NET developers to move from Web Forms or MVC to Web Pages (Razor). As a framework, it is designed to attract those who might find Web Forms or MVC too much of a learning curve. Those coming from Classic ASP or PHP, for example.
I answer a lot of questions on the Web Pages framework over at the ASP.NET forums, and I have definitely seen an increase in the number of people trying the framework out. In terms of functionality and security, you have the whole ASP.NET framework behind you so you can do anything with Web Pages that you can do with MVC or Web Forms - a lot of it more easily.
The Web Pages framework is not designed with testability in mind, and it may be more difficult for teams to organise since a certain amount of server-logic is embedded in the same file as HTML.
If you are a lone developer and happy using Web Pages, go for it.
There been a lot of discussion about the topic. Its just opinions, right tool for the right job. Please look into the following for opinions & answers:
MVC 3 ASPX VS RAZOR View Engine
Razor vs Webforms view engine for new ASP.NET MVC 3 site
What is the difference between Razor and ASPX?
Hope this helps
I think many of us used to face the same question: what's the best practice to port existing web forms App to MVC. The situation for me is that we'll support both web forms and MVC at the same time. It means, we create new features in MVC, while maintaining legacy pages in web forms, and they're all in a same project.
The point is: we want to keep the DRY (do not repeat yourself) principle and reduce duplicate code as much as possible. The ASPX page is not a problem as we only create new features in MVC, but there're still some shared components we want to re-use the both new / legacy pages:
Master page
UserControl
The question here is: Is that possible to create a common master page / usercontrol that could be used for both web forms and MVC? I know that ViewMasterPage inherits from MasterPage and ViewUserControl inherits from UserControl, so it's maybe OK to let both web forms and MVC ASPX page refer to the MVC version. I did some testing and found sometimes it generates errors during the rendering of usercontrols.
Any idea / experience you can share with me? Very appreciate to it.
Background:
This UI project has been created for years and there're 20+ people working on that. Before I start the common master page trial, there're about 50+ web forms pages and only one MVC page. We create new features on MVC, but the old pages keep remaining in web forms.
This situation will keep for a long time, probably because this's a business-driven company so new features are always in a higher priority. This means we need to support both at the same time.
There are several integration problems using ASP.NET MVC master page with web forms pages and user controls. Since the execution pipelines of the two frameworks are not exactly the same it is normal to have some problems.
One of the things I've faced is that web forms uses single interface pattern (it has one <form> tag with runat="server" on the page). In your master page or pages using it you'll have to create this tag yourself if you want to use server controls. Note that this will work for read-only controls. If you need post-back & event handling you'll probably face more problems with event handling and event validation.
Also one trick is to create html helpers that render existing controls to string. You can check this out for more info http://www.abadjimarinov.net/blog/2009/10/29/HowToRenderAspdotNETControlToString.xhtml This is also a partial solution as it will not work with most user controls.
It will be helpful to provide some code or error messages so I can give you more concrete answers. At this level I can only say that the two frameworks are compatible and you can integrate them but this will not be painless and will require some changes in the existing code.
Let me use an analogy
This will sound harsh but will make it easier for me to pass the idea across. Exaggeration helps sometimes because it emphasizes certain things that need to be understood.
Ok. We're using bicycles to get from A to B at the moment. We're considering buying a car but we want to make transition from one to the other as painful as possible. Consider the fact that we enhanced our bike so it uses custom pedals etc. Is it possible that we use these pedals and other enhancements with the new car we're considering?
Essentially it's possible. But without making a huge mess out of it it is definitely not advisable.
Suggested transition is to change pages one by one to use the new technology (new ones of course in the new technology) and not to introduce some MVC functionality to a webforms page. Either MVC or WebForms for a particular user process. Majority of non-UI code can be reused (business services, data access layer code, data/domain model when applicable). But if you're cramming all the code in your code-behinds... Well bad luck for you. If you haven't separated your code you will more or less be repeating code. Unfortunately that's not Asp.net MVC's fault. It's your bad design without SoC.
Don't combine/mix/blend two UI technologies if you're not suicidal. You can go from A->B using either bike or car, but not both at the same time. This means you can have WebForms part of your application and MVC part of it, but not likely on the same page. And this is only possible if you use Web applications not Web sites. Asp.net MVC can't work as a Web site (on demand partial per page compilation).
Re-usability related to my analogy
Bike and car are two UI technologies. What you do or the purpose of you taking the route from A->B is not important. That's business logic. If you're delivering newspapers that's not related to transport. So you can see that other layers can be reused.
Asp.net WebForms vs. MVC
Asp.net WebForms
Server-side controls (web/user) use the event pipeline execution model. Hence they (unless completely presentational nature) have server side events that some code subscribes to. Platform is completely state-full and everything executes in a manner that abstracts the HTTP completely away. Everything looks like you'd be running a desktop application.
Controls usually encapsulate presentation, code (as in server-side and client side script) and style (as in CSS). That's why it's a lot harder to have SoC using WebForms.
Asp.net MVC
This platforms is completely suited for the stateless nature of the HTTP protocol. Every request is completely stateless (unless you store some state data in persistent medium - Session, DB, etc.). There's nothing like an event model. It's basically just presentation of data/information that is able to transfer data to the server (either as GET, POST, DELETE, PUT...). Server side doesn't have any events. It's only able to read that data and act upon it. And return some result (HTML, Script, JSON, ...). No events. No state. No complex abstractions.
Asp.net MVC abstracts away some common scenarios that are related to data. Like automatic conversion to complex object instances and data validation. Everything else is gone.
Asp.net MVC using WebForms
In case you would like to use server-side controls in an MVC application you would be able to put them in your ASPX/ASCX, but they would only be used as pure presentation. You'd provide some data to render. And that's pretty much it. Postbacks wouldn't even work (unless you'd put a submit button on it), because there's no __doPostback client side functionality that would make a POST request to the server. So if there's any server side code that these controls have (even when they didn't initiate a postback) and are related to it's state-full lifetime after they've been loaded, you can say goodbye to them. More or less.
Other than that, you can read a lot about differences between Asp.net WebForms and Asp.net MVC on the internet.
Sharing MasterPages: see this thread.
User Controls:
This is one of the banes of my existence with MVC; in MVC2 and previous revs, there's no direct equivalent to webforms user controls. A sort-of workaround is creating HtmlHelpers - (effectively extension methods to the Html object available in views that return HTML), but that means you'll have to render your HTML in code. Teh suck.
With MVC3 and the Razor view engine, a new class of Html Helpers is available that provides most of the benefits of user controls, including the ability to place them in separate assemblies (and therefore can be used in multiple projects). I'll see if I can dig up an example link, but Scott Guthrie's blog had an example in one of his recent MVC3/Razor posts.
You can do a certain amount of integration between the 2, but you end up with something more complex & less satisfactory from either approach. A comprise in other words.
I've had this same problem in the past & server side includes worked for me. Old school I know & not something I'd generally recommend. But we don't work in an ideal world.
I watched a little introduction into ASP.NET Dynamic Data, and I noticed this option to create a data driven website for the first time. I have a database with a few tables, just created a Dynamic Data application out of my database and well... my application with a lot of nicely looking web pages, navigation between them and all kinds of CRUD operations was finished after 3 minutes.
OK, seriously, it isn't finished of course. There is a lot of custom logic to introduce, design to change, and also pages or relationships to remove I don't want actually to see in the web application.
But now I am wondering if ASP.NET Dynamic Data is at least a viable starting point or do I better start from scratch and create page by page? I could imagine that it might be useful to create a quick database maintenance web interface but is it good for a very customized web application? Is it in the end more complicated to modify the scaffold than building up everything from the ground?
I'm very interested in your experiences or recommendations regarding Dynamic Data! Thanks in advance!
I could never wrap my ahead around it enough to get any use out of it. At first, I thought this was Microsoft's answer to Ruby on Rails, and I was looking for the same benefit. I don't it comes close to having the same benefits. When I then compare it to a CMS (DotNetNuke, Sharepoint, Drupal, etc) it then looks really underpowered. Compared to ASP.NET MVC, it seems like going the wrong way from basic ASP.NET (MVC is removing bad abstractions from ASP.NET, while DD is adding even more abstractions).
Personally I'd rather build something from scratch in ASP.NET MVC, though my day job is regular ASP.NET. I'm also learning Drupal as I haven't found the sweet spot with ASP.NET based CMSes. One thing at at a jobsite you're going to want to use technologies everyone else knows. So I think that limits where knowing Dynamic Data is generally useful, as basically any legacy application won't be using it and you're unlikely to find a team with existing ASP.NET Dynamic Data experience.
The quick scaffolding is spiffy but at the end of the day I don't think it will make web development easier.
I very like ASP.NET Dynamic Data as it is a fast way for creating data driven applications. Customization is not a complicated task.
I wrote a corporate website with this technology from the scratch - it takes appr. 2 months for all. So my point of view that this is a good starting point for web applications development.
if your archetecture resembles ASP.NET Dynamic Data or DotNetNuke or some other starter kit, go for it, if
application is small to medium sized
you do not have strict deadlines
you are learning the technology.
otherwise or when you will be skilled in particular technology, you will prefer yourself working from scratch as it gives you more freedom and space for the implementation of ideas.
For e.g, one reason for the breakthrough for Asp.Net MVC had was many .Net developers wanted freedom over the development / architecture / flow and rendering (HTML) of the product they were building. Asp.Net WebForms does provide solid and vast grounds for swift development and templates but developers had to go according to the architecture. This freedom is available under MVC and developers can make use of nearly all Libraries and skill set available and go their own way.
one successful sample is Stackoverflow.com itself
hope this helps
I have a reasonably large project at work that I've inherited. It's an ASP.NET 2005 website project and two C# library projects for data access and some business logic. The code actually runs 6 different database driven websites. It displays different images and text for each site based on logic that examines the URL and uses a series of Web.config values and switch statements.
We now have several new websites that will follow the same pattern and framework as these 6 and so management has decided that we should not reinvent the wheel and we should continue to extend the existing code. While I understand the decision from their perspective, the thought of extending this code with even more Web.config values and even more switch statements throughout feels wrong. It seems like there should be a better way to manage this particular form of complexity, but I don't have a handle on what that better way should be.
At the same time, I've been looking for a project to start learning ASP.NET MVC and I've been leaning towards re-developing this project with it on my own time since it's complex, but the requirements are in the code. I'm looking to gain 3 things out of moving it to MVC: 1) be able to test the app and all it's versions and all it's dark corners that I don't even know exist yet, 2) hopefully find a way to make managing about 12 sites on a single code base manageable and 3) learn MVC.
After rambling a bit, here are some specific questions:
Will MVC actually offer me better ways to manage the 12 site in 1 code base issue? It's a bit hard for me to tell without having a deeper knowledge of MVC.
Is there a templating pattern or framework that I can apply (in either WebForms or MVC) that is suited for sites like these that have similar content and structure and run from the same code base?
Is there a better way than examining the URL to decide which site is being viewed and what the images and text should be displayed for each site?
Thanks for the time. I do appreciate it!
ASP.Net MVC might have some real advantages for you here. You wouldn't be manually examining URL's any more, because the Routing functionality of MVC would do it for you - so in a way, it is a "better way". Here are some advantages:
URL routing is an easy way to differentiate which site was being served, and your "which site am I" parameters would be automatically handed down to every Controller (and subsequently, every View) if you structured your routes correctly.
URL Routing works both ways, so it would be relatively straightforward for you to define a single View for all your sites that generated proper images and script references to whichever site directory you needed.
Partial Views would be a great way to switch in site-specific content in corner cases where the template wasn't exactly the same for each site.
As long as the logic was reasonably similar for each site, ASP.Net MVC 1.0 could handle this. If you need different controller logic for each site, the upcoming release of ASP.Net MVC has the concept of "areas", which would allow you to implement different sites in the same application that all had their own Controller, Model and View directories - but were differentiated by their routes.
Will MVC actually offer me better ways to manage the 12 site in 1 code base issue?
Honestly: I would not go this road. ASP.NET is powerfull enough to have a multitennant system. There are things that help to build multitennant applications in ASP.NET MVC. You have IoC for changing business rules between applications and you have the option to dynamically choose which view to render.
You have testabillity.
Thats all great: read here about it
link so
But still: It is an enourmous effort to implement such a system. ASP.NET is great (you got Routing now!) and if you have a running system better invest your time in making it better.
One of the common questions asked regarding ASP.NET MVC is why should you use it over ASP.NET Web Forms? The answer generally includes ViewState and clean URLs, amongst others. Towards the end you'll find a blurb about using the right tool for the job and that they serve different purposes. However, I don't believe I've ever seen what those purposes are. So, when would you actually choose ASP.NET MVC over ASP.NET Web Forms, or ASP.NET Web Forms over ASP.NET MVC?
You don't choose ASP.Net MVC over ASP.Net, because ASP.Net MVC still is ASP.Net. You do choose ASP.Net MVC or ASP.Net Web Forms, and there are lots of good reasons to do that:
Easier to get control over your HTML
Easier to do unit testing
Few "Gotchas"
On the other hand, Web Forms do have a few points in their favor:
Easy to put simple CRUD/business apps together extremely fast
Hard to beat ViewState performance in local LAN environment
Easy to learn forms paradigm
The result is that if you're building business apps in a corporate LAN environment (which honestly is still most web developers), Web Forms is really great. In that sense Microsoft really knows their market. But if you're building an app for the public internet, you might want MVC so you can test thoroughly and be sure your pages aren't bloated with unnecessary ViewState or JavaScript data.
Additionally, something that has changed over the last several years is that even many corporate intranet applications now need to support home/remote use, making MVC more attractive to that crowd than it had been.
Use MVC if all your team members are skilled enough to manage "control over HTML", otherwise your code will turn into a tag soup.
In other words
bool useMvc = true;
foreach (TeamMember member in team.Members)
{
useMvc = useMvc && member.IsSkilled;
}
http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx
check that blog !
Bottom line "separation of concerns"
I'll give you a couple purposes, with clear advantages.
If your purpose is a public facing website that will be banking on traffic, use MVC. It is optimal for search engine optimization.
If your purpose is an enterprise web-application that acts like a desktop app, I would lean towards web forms, since state management and compartmentalization of your resources into underlying server controls offers huge advantages if used correctly.
The biggest problems facing developers is managing complexity and keeping code "clean". MVC gives the developer the reins to leverage OOP to tuck away complexity and make code easy on the eyes.
Webforms will be faster to develop in the short term, but it doesn't lend itself to long term sustainability in terms of maintenance and growth.
I've worked with Web forms for 13 years and MVC for 2 years now and when I started with MVC, I had similar questions. Here are my takeaways.
Most importantly: ASP.NET's latest release is 4.6 and they were moving to ASP.NET 5.0, but MS abandoned that for ASP.NET Core, which no longer supports Web Forms (or even VB.NET). So, that alone might give you your answer when deciding what rabbit hole to go down.
That being said:
MVC I'm finding, once you get the hang of it, is WAY easier for dealing with basic forms and any sort of simple "Model", aka tables with a very simple, straight-forward set of relationships such as orders that have tables that link to users, products, etc. Once you start getting into some more complicated relationships and need to return lots of conditional sets of results, rely on parameters, have complicated stored procedures... then Web Forms is much better for dealing with this. If you don't have to deal with this level of complication, MVC makes development SO MUCH faster, especially with dealing with an approach where you already have the DB because it creates so much of the code and validation for you already
If you're not very experienced with database design, MVC does the work for you. It can literally build the database for you.
MVC doesn't have a lot of the built in controls that Web Forms does (Gridviews, FormViews, Sitemaps, Paged lists). Everything has to be written from scratch, but luckily a lot of people have already invented that stuff for you in NuGet which you can just download into your project
MVC relies heavily on the structure of your URL. The path, the querystring, etc. If you find your application needing to do a lot of form POSTing instead of GET-ting, you're going to have to do a lot of tweaking or AJAX posting. If you have a set URL that can't change, it can be a pain. It's doable, but just a little tricker (or you can just use Angular instead).
MVC has no Viewstate. If you need to hide variables from post to post and persist them, it's a little difficult. MVC Does have things like ViewBag which lets you pass data from your controller to your page, but it clears after the page is rendered. There is also something called "Tempdata" which acts like Session state, but more temporary. However, it relies on Session State which is not an ideal way of persisting data. Session variables and tempdata variables are fine for user-level data (profile information for the person logged in), but having two different tabs open by the same user can cause these session/tempdata variables to overwrite each other when you're dealing with the actual model data.
If you're at a crossroads, I'd go with MVC. MS is pushing it and support for Web Forms will likely start going away