How to Web with ASP.NET

Microsoft is working steadily on the next generation of web development with their ASP. NET Core 1.0 platform release. Sam Basu and I recently conducted a webinar about choosing the right tech stack for your ASP.NET app. Although we covered the various features and capabilities of the myriad options available, a common request by attendees was to better understand how to choose the right stack.

This is a great question, and one that comes up often when starting new web development projects. As a consultant, I work with companies in multiple verticals. They have different infrastructures ranging from on-premise servers to wholly cloud-based solutions. Some companies have large, mature development teams and others are looking to outsource all of their information technology needs. Given so many factors, what is the best way to choose the right platform?

The Players

First, it’s important to understand the matrix of options that are available to Visual Studio developers.

At the common core is a consistent experience using either one of the full-fledged Visual Studio versions or the lightweight, cross-platform Visual Studio Code. You can certainly use other Interactive Development Environments (IDEs) but these are by far the most common for .NET development.

ASP.NET Stack

ASP. NET

The first choice is whether to use the Windows-based .NET Framework in conjunction with ASP. NET 4.6, or the newer, lighter weight and cross-platform ASP. NET Core 1.0. Both have similar programming models and capabilities. So how do you choose one over the other?

Windows Support

ASP.NET 4.6 runs on Windows-based machines and relies on the full version of the .NET Framework. Many servers today run Windows-based operating systems and there is a vast library of off-the-shelf components available to do everything from retrieving data directly from medical equipment to scan text and route reports to printers. Many developer tools were designed to run in this environment.

Key Decision Point: If your environment is primarily Windows-based, and especially if your apps heavily rely on third-party software designed for Windows, this is probably the platform you’ll want to use. It is compatible with your existing code base and libraries and well supported in the enterprise.

Cross-Platform Support

ASP.NET Core 1.0 is a lightweight, modular platform for building web apps that can run on multiple platforms including OSX and Linux-like operating systems. Its smaller, optimized footprint makes it ideal to run on commodity servers and/or in containers.

Key Decision Point: If you are running an infrastructure that requires the web nodes run on non-Windows platforms, or if container management is part of your DevOps strategy, this is the platform of choice for you.

Other Considerations

Even if your target is Windows-based machines, the .NET Core platform may provide advantages. These include:

  1. .NET Core is the most current platform;

  2. .NET Core is open source, so your team can contribute to the project with enhancements and fixes (read how one company helped improve performance by 2300%);

  3. .NET Core has a smaller footprint and is highly modular, enabling you to choose only the dependencies you need;

  4. .NET Core is highly scalable and has demonstrated the ability to handle millions of requests per second.

Key Decision Point: If you want a lean, streamlined approach to deploying web nodes (including pages and services), this is the platform to consider.

image_16945E20
Image courtesy of Microsoft

MVC and WebForms

Another common decision is between MVC and WebForms. There are very important differences between the two.

WebForms

WebForms was the original engine that Microsoft provided with .NET. WebForms bridges the gap between traditional desktop development and the web by providing abstractions over the way the web functions. Because HTTP is a stateless protocol, WebForms provides a mechanism to preserve state through a construct called View State.

Some of the pros of WebForms include:

  • Reusable controls with a drag-and-drop design interface;

  • Auto-management of events through a “code-behind” paradigm;

  • Large ecosystem of third-party controls and utilities;

  • Short ramp-up time for non-web developers.

Like all technologies, using WebForms comes with trade-offs. Some of the cons include:

  • ViewState can become massive and generate unnecessary overhead and reduce performance;

  • Unit testing of WebForms pages is not straightforward;

  • HTML bloat: the WebForms engine manages most of the HTML so it may render bloated and inefficient markup;

  • Search engine optimization – WebForms pages out of the box are not indexed in a fashion that is friendly to search engines.

MVC

mvc

MVC is a design pattern and stands for Model-View-Controller. The MVC engine was given its name because it supports this pattern. It provides a distinct separation between the HTML view, the C# model, and the server-based controller. MVC supports a more traditional form of web development and has been embraced by the broader web developer community. Advantages of MVC include:

  • Widely adopted pattern for building web apps;

  • Testing is first-class;

  • Full control over authoring streamlined HTML;

  • Easier to build out parallel development teams to work on aspects of the same application simultaneously;

  • Routes are user-defined and are more user-friendly and SEO-friendly out of the box;

  • ASP.NET on the server: all existing server aspects, such as built-in authentication, are still available.

Disadvantages include:

  • Bigger learning curve for non-web developers;

  • State is no longer managed passively and must be explicitly managed by the developer (although some would argue this as an advantage);

  • Lack of compatibility with existing WebForms controls: this is a disadvantage when migrating legacy code.

For a walkthrough on how to set up a new MVC project using ASP.NET Core, check out Ed Charbeneau’s tutorial

Which to choose?

Key decision point: If you are looking to have more control over your application, better performance, a clear path forward to newer versions and an easier job finding developers, MVC is the right path. I don’t recommend WebForms for new projects and consider it only for compatibility to support legacy projects migrated to more current versions of the .NET platform.

Traditional vs. SPA and AJAX Models

In addition to the engine you choose to serve your web application, you also have a choice of how you manage the front-end aspects or browser-based portions of the web. Some applications follow a more “server-centric” model where the server renders most of the content and users browse the app by navigating from page to page. In traditional WebForms parlance this is a “postback” paradigm.

WebForms and MVC can both work with AJAX to make asynchronous calls (or “callbacks”) to the server. This allows content to be updated dynamically without having to refresh the entire page. Developers can leverage existing controls in WebForms by using controls like the Update Panel. For MVC, libraries like jQuery provide an easy mechanism for issuing HTTP requests.

Many modern apps are built as “Single Page Applications” or SPA for short. A SPA app has a simple page that renders the basic structure of the application, including any stylesheets and JavaScript libraries that need to be included. After the initial load, the client (browser) manages the rest of the app. The application issues simple web service calls that return JavaScript Object Notation (JSON) objects, and templates transform the data into information-rich HTML.

The choice of model depends on the needs of the application. Most users expect a familiar, rich desktop-based experience, and the SPA approach makes this possible. It can connect to existing middleware APIs and services to get data and leverage the users’ processing power to render the app. Users perceive improved performance because the server doesn’t re-render entire pages, but only the portions that change. Often a JSON payload can be delivered with less latency than fully-rendered HTML.

Key decision point: If you are migrating a desktop app or providing a rich, interactive experience, consider using a SPA framework for your app. The most popular SPA framework now is Angular.

Whatever your next project, the cost-efficient product bundle Telerik DevCraft features controls for all three technologies—WebForms, MVC and Angular (via Kendo UI) —packed together with .NET productivity and code quality tools.

Download a fully functional 30-day trial of Telerik DevCraft.

The Factors

Now that you are familiar with the options, you can start to dig into various factors that will affect the decision to commit to one model over another. Although this is not a comprehensive list, here are some of the most common elements we encounter when deciding upon a framework to use.

Legacy Support

Many customers have existing systems built on WebForms and invested heavily in third-party controls. For these systems, it is important to weigh the cost of moving to a modern web stack (such as MVC and Angular) against the existing investment and ability to migrate to the current version of WebForms.

This decision is much easier if the application already follows an N-Tier design. In that case, much of the business logic and data flow can be reused. If the application is 2-tier, and most of the business logic and data access exists in the code-behind for WebForms pages, the migration will be much more costly. One compromise would be to migrate to WebForms and refactor business logic in a middle-tier, enabling the path forward to a more modern web stack in the future.

Customer Requirements

The customer requirements are very important and will heavily influence the decision. For example, if the need is to have a simple Create/Read/Update/Delete (CRUD) model with a list that you select and edit, any of the available models will work fine. However, if there is a more complex workflow or the need to compose a rich user experience on a single page, then a more modern web stack with a SPA front-end will be more applicable. Fortunately, modern frameworks and tools enable a very streamlined front-end experience.

Speed to Market

There are traditionally three drivers behind any software project:

  • Scope, or the universe of things to do;
  • Budget, or how many funds are available to get things done; and
  • Time, or when things need to get done by.

If time is a constraint then the model you choose will be heavily influenced by your ability to deliver to market on time. For example, if your existing team has experience with MVC but has never worked on a SPA app, you may want to avoid the cost of ramp-up and knowledge transfer to get the product to market.

On the other hand, frameworks like Angular make it possible to rapidly prototype and iterate on solutions. The larger the team, the more likely it is you’ll want to follow a MVC + SPA stack because existing frameworks prescribe a component-based approach that enable you to scale an effective team that works in parallel and writes meaningful tests to improve your product’s quality.

Team Knowledge and Experience

It is important to consider the team when determining which framework to follow. The various .NET versions share similar languages and APIs. Moving to a SPA-based application can be more difficult, especially if your team is not well-versed in client-side code and JavaScript. Technologies like TypeScript can help shorten ramp-up time and make it easier for the team to scale large JavaScript projects.

Team Size

The team size is very important to consider. If you have a small team it is sometimes more important to stick with a technology stack that they are familiar with, especially when timeline is a priority. With larger teams you should focus more on modular, testable code and enforce standards that may take a while to adopt but will eventually allow you to scale the team to larger numbers and improve speed of delivery.

Summary

For most modern web apps, we choose a technology stack that includes traditional ASP.NET and leverages Angular to enable a SPA-based solution. The tool stack is widely supported by the .NET development community and existing tools enable us to deliver more quality software faster than other methods.

If the customer has already invested in a specific stack or relies on a team with heavy knowledge and experience in a different model, we’ll either accommodate that model or focus on specific training to help transition the team and share best practices to create a solid foundation for transitioning to a new technology stack.

We are also very excited about basing future projects on the new .NET Core as it moves out of beta into general release. Telerik is committed to supporting whichever technology platform you choose by ensuring that their controls will run on ASP.NET Core and integrate seamlessly with third-party frameworks like Angular.

Related Resources

728x90

Comments

  • Pingback: Dew Drop – May 4, 2016 (#2243) | Morning Dew()

  • B. Clay Shannon

    Why does “MVC” appear twice in the chart (both with “Traditional” and “SPA”)? Was one of them meant to be Web API? … Oh, I see – one is through ASP.NET 4.6 and the other through Core 1.0. Still, though, I wonder – why no mention of Web API? I have a solution with two projects, one of them being MVC (ASP.NET 4.6) and the other a Web API solution. I believe both were the right choices for the project types, but wonder why Web API is being ignored or “dissed”…

    • Jeremy Likness

      Hi,

      It’s not. I’m focused on the web app delivery for the article, not the middle ware. Web API is a perfect way to deliver services and payloads, but you can also use ExpressJS or connect with a third-party service, etc. Web API is definitely a component but it’s typically a tier of it’s own so shouldn’t drive your technology decision for the presentation layer (you may have Windows servers running Web API end points and still use containers on Amazon AWS to host .NET Core nodes for the UI, for example).

  • Pingback: The week in .NET – 5/10/2016 | .NET Blog()