16

Should I stick with Webforms?

I currently work for a Digital Agency and I have been tasked with building a new website for one of our clients based on Sitecore.

I have a couple of years of experience with C#/ASP.NET. Up until now most of the work I have done has been on ASP.NET Webforms, but I understand that Sitecore (and the industry as a whole) is moving away from Webforms onto newer technologies such as MVC, React, AngularJS and so on.

My worry is, that if I start a new project on a platform I am new to, would I not be better off sticking with Webforms to try and minimize the learning I have to do?

And if not, why not? The alternatives seems to be MVC, AngularJS and React, but I am unfamiliar with all of them. I do know a bit of MVC, but I wouldn't consider myself "experienced" with it.

I've been doing a bit of research on my own, there seems to be plenty of examples around on how to do Sitecore based on Webforms, even if some of the posts are a couple of years old by now.

Requirements for the site seem fairly straight forward. I will not need to integrate any third party tools or legacy code into my new solution.

  • If the requirements are fairly straight forward I'd look at this as the perfect opportunity to dive into a new type of Sitecore project. I see a few reasons for staying on webforms. They are how comfortable you are with them and having custom code/frameworks built around them. Ex: any base user control would need to be reworked if you changed off of web forms. I don't feel qualified to answer this question but am interested to see what other people say. – Teeknow Aug 18 '17 at 14:50
  • 2
    Yep the question comes up often, yet was never asked here. Which is why we're putting it on record :-) – Mark Cassidy Aug 18 '17 at 14:56
13

For me I always use WebForms for POCs because its so fast and easy. But for projects I 95% of the time use MVC. The 5% being for a client requirement where existing projects are WebForms and they want to keep that.

I use MVC for the projects because:

  1. Much of the demo code you find and want to steal (I mean borrow) (i.e. Habitat, uCommerce) is in MVC.
  2. Top level developers will want to MVC to match their desired patterns.
  3. The project is much cleaner, using MVC, when developing in architecture like Helix.
  4. Using Sitecore's IoC container is much simpler in MVC.
  5. Testing is MUCH simpler in MVC. So then developers will actually do it.
  6. Sitecore's codebase seems focused on MVC since its almost completely written in MVC.
  7. Using next level technology like JSS will require the user of API controllers that you will most likely already have.

I struggled to move from Forms to MVC a few years back. But the effort to get there was worth it for the outcome. Make the switch, you will be a better developer for it.

My 2 cents.

8

A lot will depend on why you are asking this question. WebForms are not going anywhere anytime soon - there are too many legacy implementations out there that use WebForms - for Sitecore or Microsoft to not have support for it... But...

There are a lot of problems with WebForms as a framework. With MVC you get a better development experience (see what I did there) and can produce (IMO) a better quality implementation.

Some of the benefits:

  • Full control of the markup - For projects with dedicated front end teams, this is a massive bonus. If you have ever tried to shoe-horn dedicated front end markup into a WebForms page - it can be tricky
  • No ViewState - view state is often misunderstood by developers and can kill page weight and performance when not dealt with properly
  • UNIT TESTING.... do I need to say more? I mean, sure you can unit test your service and repository layers with a web forms implementation, but you can't test any code that devs put in the code behind... and while I'm on that subject...
  • DI/Inversion of Control - again - you can do it with WebForms, but its not fun.

I have heard devs say that you can get projects built faster with WebForms - but I would argue that is only if you don't know MVC well - I have been doing MVC for a while now and there is no way WebForms development is faster, you just have to learn it.

Ultimately I would say the only reason to use WebForms in a NEW project would be if you had zero developers that know MVC and your project timescales and budget do not allow for the learning curve of MVC.

If you did decide to use WebForms for a new project, be sure that if you think its hard to find Sitecore developers - its just as hard to find a talented developer that wants to stick to WebForms - the trend is towards MVC, WebForms is old news - I certainly wouldn't take a position with a company if any of the projects used WebForms, just not interested in it. So resourcing could become an issue.

Its already been mentioned, this will be an opinionated answer - but I'd be willing to bet that 9/10 of the opinions will be - Use MVC!

  • I agree whole heartedly. Top Sitecore devs see forms and run. – Chris Auer Aug 18 '17 at 16:13
3

This will probably get me downvoted to oblivion, but I still like WebForms for lots of reasons. My move to MVC is only going to happen completely once tag helpers are being used throughout Sitecore, so we can finally stop putting code inside Views.

If you want to use WebForms, however, strongly consider a pattern like Model-View-Presenter. There is an excellent framework called WebFormsMVP that will provide a solid support structure as well as inter-component communications that are very important in a component-driven CMS, and still not well done in MVC.

Just because WebForms allows you to do silly things like backing a table with ViewState, doesn't mean you have to do it. You can't build a robust, professional site with WebForms if you know what you're doing. As with so many things, the onus is on you to do it right. You can make a huge mess of MVC without trying too hard if you don't know what you're doing. So we're clear, putting logic into code-behind is the equivalent of "not knowing what you are doing".

The MVP pattern will support a range of Helix-compliant, fully testable, SOLID, TDD-driven practices. The result will be fully compiled at design-time, and highly performant if you've done it correctly. You will also avoid a half-dozen or so Sitecore rendering pipelines.

I know there isn't much love on the web for WebForms these days, but don't be fooled by zealots. It's just as easy to mess up MVC by putting methods in your models and executing business logic from your views as it is to mess up WebForms by dragging toolbox components to your "design surface" and forgetting to manage your ViewState.

A word of warning in parting: WebForms controls emit HTML (some MVC calls do too by the way) - so if you want to have very strict control over the HTML output you are going to be forced to either: a) lean on LiteralControl, or b) create a number of Server Controls of your own. That's not especially difficult, but it will add some build time to your project.

Remember that in Sitecore, neither WebForms nor MVC components are executed in their "native habitat", and that Sitecore is faking the component lifecycles in both cases.

  • To oblivion and beyond!! - Buzz Lightyear – Chris Auer Sep 19 '17 at 18:12
  • Unfortunately the WebForms vs MVC debate has stopped being a sensible technology-based discussion of what's appropriate to a zealot-driven diatribe of rhetoric that simply brands anyone in the WebForms camp as a witch that must immediately be burned at the stake. But yeah... go team MVC. shrug – Richard Hauer Sep 20 '17 at 1:13
1

If you're brand new to Sitecore, and you're brand new to MVC, I would use MVC for your first Sitecore project. It will allow you to get embedded in the current direction the product is going without learning any bad habits.

Being new to MVC is a bonus, because Sitecore's implementation is very different from "stock" Microsoft ASP.NET MVC: There's no routing required (Sitecore handles it) and what you would likely consider a "partial view" or "child action" in Sitecore is actually neither of those. Just color within the lines of available tutorials, pick a framework like Glass that basically takes all the configuration off your hands, and you'll be fine.

1

Just to add another angle for this. The future of Sitecore is .NET Core, which doesn't support WebForms. While the full migration to .NET Core is a number of major versions (and thus years) away, you're essentially condemning yourself to a future refactor or even rebuild.

Having said that, pragmatically speaking the trade off of efficiency might be worth it for your particular usecase.

The alternatives seems to be MVC, AngularJS and React

MVC is the only actual alternative. AngularJS and React are both client-side (browser) technologies and could be used with either MVC or WebForms.

  • It is only a matter of time. Microsoft's last several years of effort on their newest frameworks .NET Core and .NET Standard (which are: Cross-platform, Open source, Flexible, and Modular) allow you to easily Opt-In support for MVC (Modular), but have clearly stated they do not support WebForms. So the real question is the "shelf life" of your solution. If you go WebForms, it is limited at best. If you go MVC, the future becomes unlimited for the longevity of the code that you spend your time, money and energy writing. Thereby, reducing the risk/need for a rewrite/replatform in the future. – Radical Dave Oct 20 '17 at 22:08
0

You should always use MVC for your Sitecore projects even if you replace the view and go headless having the models and controllers separate will provide you with a cleaner architecture. WebForms is disappearing and so any work you do in it will be throw away as you move to future versions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.