OdeToCode IC Logo

You Want To Build Web Software with C#?

Tuesday, February 12, 2013

If you like choices, you've come at the right time. You might think the decision making process starts by choosing between ASP.NET Web Forms and ASP.NET MVC, but if you widen your perspective a bit you'll find there are even more options outside the confines of the File –> New Project dialog in Visual Studio. And, these choices have steadily increased and matured over the last few years.

Here are just a few of the other options for writing a web app today:

- Nancy (lightweight and low ceremony)

- FubuMVC (convention-based and highly compositional)

- OpenRasta (a resource oriented framework for web sites and APIs)

- Service Stack (a web services framework)

- Oak (highly dynamic, frictionless)

Even when you restrict yourself to frameworks from Microsoft, there are still a bewildering number of decisions to make. Web Pages, Web Forms, Web API, or MVC?

Making A Decision

Ultimately your job is to ship working software, and be happy about shipping the software. It's hard to build an application when you loathe working with the underlying technology. If you are brand new to all of this, I believe one of the first steps is to sit down by yourself and with your team, and figure out what you like and dislike about the available frameworks. If you are brand new to all of them, it would be worthwhile to spend a couple hours with each. Read about their design goals. Read the code examples as they will demonstrate the code you'll be living with.

Some of the questions to ask at this period include:

- What are my business requirements? Do I need to optimize for both mobile and desktop? Do I need to be highly scalable? What sort of authentication mechanisms do I need for my customers? Am I building a site, a service, or a combination of both?

- Do the abstractions make sense to me? Do the abstractions relate well with my mental modal of how things work on the web?

- What do I value the most? Testability? Flexibility? Simplicity? Past experience with an existing framework?

- What are my technology requirements? Am I tied to IIS and Windows or do I want the ability to run on Mono? Do I need to build an application that makes heavy use of JavaScript in the browser?

You have to answer these types of questions and narrow down the field based on how you perceive the capabilities of each framework. You can build almost anything with any of the above.

Eventually I'd recommend narrowing selections down to 2 or maybe 3 frameworks, then writing some code with each to get a good feeling for a what life with the framework is like.


When people ask me what to use, I tell them the choice of framework (and language) is a very personal choice. You have to evaluate questions like the questions listed above to figure out for yourself what framework will be the best for you, your team, and your business.

There are only a few hard and fast rules I can proclaim on this day in the month of February in the year 2013.

When starting a new application today:

- Do not use Silverlight

- Do not use LINQ to SQL

- Do not use WCF, unless you have no other option (e.g, to build a SOAP API).

- Do not use the Web Forms view engine for anything but a Web Forms application

- Don't forget:  in larger applications the web layer is just a façade. Other architectural decisions should probably have a higher priority.

Gravatar Randy Minder Tuesday, February 12, 2013
Interesting article Scott. I'm curious why the recommendation to avoid WCF. And what would you recommend instead?
Gravatar Mike Chaliy Tuesday, February 12, 2013
Quit funny that you first recommend to use Web API and then "Do not use WCF"
Gravatar Scott Tuesday, February 12, 2013
Yes, look at using the Web API first, instead of WCF. The WCF framework is great for SOAP, WS-*, and binary protocols, but doesn't have the reach (among other things) that you can achieve with the Web API framework.
Gravatar Kevin Major Tuesday, February 12, 2013
Can you explain/link to an explanation of "No LINQ to SQL"?
Gravatar Mike Mooney Tuesday, February 12, 2013
Aw, why the hate for LINQ to SQL? They may not be developing it any more, but it's a million times better than EF if you need to get running with an quick and easy SQL ORM. What would you recommend instead, if you don't want to go down to the metal with a microORM?
Gravatar Pablo Cibraro Tuesday, February 12, 2013
A good thing about all those frameworks you mentioned is that they don't differentiate web applications from services, as they all the same thing (an http interface for your app). No need to use two different models like MVC or Web API.
Gravatar Phillip Tuesday, February 12, 2013
I've been doing things the old way for some time now ( POCO/ADO/stored procedures) and was just starting to get familiar with LINQ to SQL. I was a curious as to why you wouldn't recommend it.
Gravatar Scott Tuesday, February 12, 2013
I like LINQ to SQL. It is easy to use, but I think the EF DbContext API is just as easy to use if you want an ORM with change tracking. EF is also getting better, adding async support and YADR (yet another dependency resolver) in v6. Frameworks like Massive, Simple.Data, and Dapper are great, but I realize they are a personal choice, too :)
Gravatar Demis Bellot Tuesday, February 12, 2013
Note: ServiceStack is also a web framework (http://www.servicestack.net/) i.e. with multiple HTML view engine support, that also does SOAP (https://github.com/ServiceStack/ServiceStack/wiki/SOAP-support) as well as REST and MQ with the same service. So it's another alternative to WCF if you need to implement SOAP.
Gravatar Demis Bellot Tuesday, February 12, 2013
Eh, the link to the Web Framework part of ServiceStack was meant to be: http://razor.servicestack.net/ :)
Gravatar Scott Tuesday, February 12, 2013
@Phillip, @Mike: LINQ to SQL is still supported and works great, but is no longer adding new features.
Gravatar Mike Mooney Tuesday, February 12, 2013
EF has the same motto as SharePoint and TFS: "Sure, this version sucks, but don't worry, the next version is going to be great!"
Gravatar Scott Tuesday, February 12, 2013
@Mike: Good point. @Demis That's great! I didn't know that.
Gravatar Phillip Tuesday, February 12, 2013
Thanks, Scott. EF DbContext API is also something I'm digging into and I'm certainly enjoying it. So much simpler than how I currently do things. In fact, starting up an new vanity project just so I can try some new things out.
Gravatar Clinton Gallagher @virtualCableTV Tuesday, February 12, 2013
No Silverlight per se implies do not use Visual Studio LightSwitch
Gravatar Guy Tuesday, February 12, 2013
I've looked at most of those other alternatives to ASP.NET MVC and they suffer from poor/no documentation and limited/no support, various states of completion, and an uncertain development roadmap. If you want to do C# web development use Web Forms, Web API or ASP.NET MVC. If you don't like any of those, you probably want to try another language/framework (Rails, Django, PHP, Node, etc). A micro web framework that I thought had promise was TinyWeb. It has decent documentation and support for the Razor and Spark view engines. I don't think anyone is actively developing it anymore though... https://github.com/martinrue/Tinyweb
Gravatar Stacy Tuesday, February 12, 2013
Asp.net has evolved randomly into many choices while leaving you stuck in yesterday's webforms, website projects, web application projects, etc. I would recommend limiting your exposure to Asp.net for "web apps" and move to the client side using one of the many javascript frameworks out there. Use MVC4 or Web API for the thinest possible http api to connect to your c# backend. I would stay away from EF to avoid an upgrade hell dependency, or abandoment.
Gravatar Giscard Biamby Tuesday, February 12, 2013
Another option that people might want to consider is Orchard (http://orchardproject.net/). While it's a CMS, you don't have to use it as a CMS. I use it as a web app framework. It has a nice theming and layout structure that is better than the default ASP.NET MVC one -- way easy to push content around to different zones/areas of your layout. Out of the box you get dependency injection (autofac), ORM (NHibernate), and support for many different RDBMS's (mySQL, MSSQL, pgSQL, SQLCE, and SQL Database AKA SQL Azure). It has a module system based on nuget, but I just clone the source for modules into my projects directly as sub-repositories because that lets me fork and modify them. There are modules for things like resource bundling and minification, there is a lot of support for Azure as well as deploying on standard hosts. It also has very useful out of the box support for database migrations. There are modules for sitemaps, SEO ones, etc; all the stuff you see in the Wordpress world, but in .NET, for Orchard. Out of the box you also get Lucene.NET based indexing and search. One of the things I like most is that you can replace anything with a custom implementation, either by using your own module, or by suppressing dependencies and providing custom interface implementations. Service Stack stuff looks really awesome, and I'm sure it's a better option than using Orchard as a pure web app framework, and definitely better than Orchard for a services framework. I also really want to try out NancyFX. I'm only using Orchard because I know it really well, and when I need to start a new project I don't have time to learn a new framework. When I need to get an app started really quick I just do twitter bootstrap + HTML5BP + Orchard, and i tend to ignore most of the CMS stuff unless it's a project that requires that. This gets me started with a full website with login, search, CMS back-end, and lots of modules to add features I need within a couple of hours.
Gravatar Daniel Lo Nigro Wednesday, February 13, 2013
Entity Framework is much better than LINQ to SQL if you use Code-First (http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx). No autogenerated code or designers to mess around with. Entity Framework also works with RDBMSes other than SQL Server (for example, MySQL). I was trying out ServiceStack ORMLite which is a very good Micro ORM. I'd recommend it if you're looking for something small and lightweight (I used it for my blog). Simple.Data, Dapper and PetaPoco also look nice, but I haven't used them as much as ORMLite.
Gravatar anonymous coward Wednesday, February 13, 2013
"Don't forget: in larger applications the web layer is just a façade." If only that were true!
Gravatar Mark Rendle Wednesday, February 13, 2013
Obligatory plug for Simple.Web: http://github.com/markrendle/Simple.Web Lightweight, fast and REST/HATEOAS focused.
Gravatar Aaron Wednesday, February 13, 2013
Do not use WCF? Why not? ASMX services are now considered legacy... so what else to do when working within SOA? Do not use EF is a better rule imo! Think I'll stick with WCF. Sure, the binding config is a bit of a pain but otherwise, I'm happy. Please tell me why I shouldn't be!
Gravatar Kyle Wednesday, February 13, 2013
Love EF! For CRUD apps I would not use anything else. It just makes it simple. For read-only apps I still use straight ADO.NET for performance reasons. WCF is crap. ASMX services perform better and are less complicated to config.
Gravatar David Roh Wednesday, February 13, 2013
We are starting a new LOB app and we are using Silverlight 5 because even though it is no longer actively supported by Microsoft (like so many, many other technologies), it is still simply the best client technology available - that's my view and I am sticking with it! :-)
Gravatar Alexis Santos Wednesday, February 13, 2013
The final exam for the MCSD: Web Applications certification has is very WCF-heavy. I'm a little surprised you suggest to stay away from it.
Gravatar James Horn Wednesday, February 13, 2013
I understand why the comment about no Silverlight but I think MS doesn't realize how many companies and developers embraced it for use in big business. I think it is more widely used than they realize.
Gravatar Scott Wednesday, February 13, 2013
@Clinton: I believe Lightswitch has (or is working on) an HTML 5 client. @Guy: Yes, you and many others place a high value on good documentation and support. Nothing wrong with that. @Stacy: You still have to place something on the server. Client side JavaScript frameworks don't build services for you. @David (and other Silverlight fans): The Silverlight story is a debacle for Microsoft from any perspective. I think one reason people avoid Window 8 development is the amount of churn and obsolescence in managed APIs for Windows. . @Alexis: The MCSD exams are out of touch with the real world, and the topics are mostly driven by politics, certification specialists who have a vested interest, and tight schedules. I remember when WCF appeared, the MCSD exam that arrived that year covered one the WSE frameworks that built on top of ASMX services. WSE and ASMX were abandoned technologies at that point.
Gravatar Joe Wednesday, February 13, 2013
I really liked Silverlight, and hoped it, along with Moonlight, would take off. A single unified app for desktop or web on Linux or Windows. Sigh... Anyways, since people are chiming in with votes, mine is to ServiceStack and MVC3/4. It has to run on Mono for me to even put it on a consideration list.
Gravatar mark Wednesday, February 13, 2013
Silverlight IS still "supported" until 2021. They just probably aren't going to do anything new with it. And they are going to discourage using it because they don't get any money from it like they do for a Windows 8 app from the store. But it was and is a great technology and I will continue to develop with it for the next 5 years I suspect. Unless something as good comes along.
John Wednesday, February 13, 2013
Rofl dont use wcf? Then mention your alternative? How do you do SOa or are you the kidn of guy who connects to the database straight from your web site? Have you worked on anything scalable?
Gravatar Nyron Wednesday, February 13, 2013
Excellent article, its nice to know that as a developer on the ms stack we have all these options if one is not suitable we can try something else. When it comes to working with data, performance is the most important thing for me, as such I still use pure ado.net.as for the web framework, i am current using MVC 3/4, I have been reading on a few of the ones mentioned. I have also created a web application generator, which generates the data access layer, based on ado.net, as well as the web app,base on mvc. All I need to do is create the database first(currently support ms SQL, although I've started some work with mysql and oracle support) and then point the generator to the DB and the app is generated, it supports caching via SQL dependency, foreign key referencing, stored procedures can be mapped to custom methods and all the views and controllers are generated(basic CRUD operations). Then i can start working on the main business logic of the project such as transactions etc. So far its been working well, its not perfect but it helps me get started on new projects. As for the micro ORM I really like petapoco and dapper. I have been playing around with web a pi and haven,t had an issue with it, as for wcf I think the amount of configuration that is needed to do some things is the main reason I tend to not want to use it, I used it for a project at work that involve distributed transactions and it was not a pretty sight, too much configuration was needed. But maybe I don't fully understand it so, I won't go as far as to say stay away from it, if it does the job better than the rest then that's what you should use.
Gravatar Scott Wednesday, February 13, 2013
@John: I mentioned several alternatives in the post, including the Web API framework from Microsoft. I think you'll find HTTP services are generally easier if you want to reach more clients (both in terms of numbers and scalability, but also in terms of platforms and reach).
Gravatar Mike Wednesday, February 13, 2013
Your alternatives list is lacking: Should also consider node.js, backbone.js, bootstrap, etc... And a few other micro-frame solutions based on the new paradigm of lightweight. Comes at a cost in other denominations: You don't get something for nothing as they say... Also I've personally coded very big well-known brand sites on MSFT technology. Never did we feel that we were "restricting ourselves to a framework". This article comes off biased against what MSFT has to offer, which legitimately has it's place. Ideally the technology would be suited to the conditions and requirements of the problem space.
Gravatar Scott Wednesday, February 13, 2013
@Mike: Good point, but to be fair I set a scope for this post in the title by saying "C#" - implying server-side code with one particular language in mind. I don't have the time to write about the full range of choices :)
Gravatar Peter Thursday, February 14, 2013
We switched from "LINQ to SQL" to BLToolkit: it's faster, much much faster, about as fast as Dapper and other micro-ORMs. Our pages render between 2 and 3 times faster. You can still use LINQ to write your queries, so you keep type-safety (thanks to LINQ) and use POCOs, no more magic strings. Thinner layer, closer to the metal / SQL; for example, you can actually write a DELETE/UPDATE statement to modify records you haven't loaded in RAM. Works with a lot of other databases besides SQL Server (like MySQL, Postgre, Oracle, DB2, etc), and it runs on Mono.
Gravatar PeterB Thursday, February 14, 2013
Scott, I believe confusion here is that you are really saying that we should be building web services using the REST-based architecture (or simple HTTP services) rather than SOAP. And that the Microsoft technology to use for that is Web API. Those of toiling in corporate IT shops still need to build and support SOAP, and for that WCF does the job. But slowly the wheel is turning. All the new public APIs I'm building now are going to be REST-based - and for that we'll use Web API. I'm surprised no one here mentioned nHibernate as an alternative to EF. People can really get religious about these things, and where I work no one will even consider EF given it's poor history. A lot of that is based on perception rather than experience. And we always tend to favor thing with which we've had experience. But then again, we're moving from something called MyGeneration - so anything we replace it with will be a vast improvement.
Gravatar JeffreyK Saturday, February 16, 2013
@PeterB Yes, a good point -- for REST services use Web API. However, Giscard Biamby mentioned NHibernate in his post about Orchard. I'm glad he mentioned it, because I've looked at Orchard a few times but have not used it. Now I'll have to try it out. Orchard CMS is listed in the Open Source section of asp.net site: http://www.asp.net/mvc/open-source. Also, Microsoft has developed a few sample applications using the JavaScript frameworks. Knockout.js is used in the Single Page Application (SPA) demo (Knockout.js is available from NuGet gallery). Article: http://www.asp.net/single-page-application Sample (ToDo List) : http://www.johnpapa.net/insidespatemplate/ There is an article on asp.net site about SPA/Previous Version (a version of SPA in the MVC 4 Beta). http://www.asp.net/single-page-application/previous-version It includes a sample called BigShelf. It incorporates a number of the current technologies in a complex but understandable architecture. (Please comment if you agree/disagree.) http://www.asp.net/single-page-application/previous-version/sample-bigshelf-application I have not studied this sample, but we looked at a simpler sample (ToDo list) in our user group this week. jQuery and several others are used in Microsoft Web technologies/frameworks/sample apps. Perhaps we need a new framework to pull together all these other frameworks! Although the BigShelf was built for the Beta release of MVC 4, it provides some interesting ideas. Let's hope this is a starting point for incorporating all of these server/client technologies into one cohesive model.
Gravatar Han Sunday, February 17, 2013
Scott, Could you elaborate a little more on "Do not use the Web Forms view engine for anything but a Web Forms application"? The reason why I ask is b/c we use DotNetNuke (which is Web Forms based). Thank you.
Gravatar Scott Monday, February 18, 2013
@Han: I believe DNN falls under the web forms category.
Gravatar jason palmer Tuesday, February 19, 2013
great stuff, found your blog via a response on the asp.net forums about global.asax, your answer about ensuring it in the root worked wonders for me !... you da man !
Tuyen Nguyen Wednesday, February 27, 2013
Hello Scott, I'm a subscriber of Pluralsights and I have watched quite a few of your videos about C#, ASP.NET MVC, LINQ... Your videos help me a lot at my work place. I find reading this post is interesting, especially the 4 "DO NOT" in the recommendation. Could you update this post and add the 4 "DO" in the recommendation so people will know what do you recommend to do building an application from scratch? Ex: When starting a new application today: - Do not use Silverlight - Do not use LINQ to SQL - Do not use WCF, unless you have no other option (e.g, to build a SOAP API). - Do not use the Web Forms view engine for anything but a Web Forms application - Don't forget: in larger applications the web layer is just a façade. Other architectural decisions should probably have a higher priority. - Do use .......................... - Do use .......................... - Do use .......................... - Do use .......................... I know this is totally a personal reference but I'm curious how would you recommend.
Gravatar Scott Allen Wednesday, February 27, 2013
Hi Tuyen: Anything else is fair game and really comes down to what you like to use, so since you asked ... For web apps I like to use ASP.NET MVC and the Web API with Razor, jQuery, AngularJS. I like Bootstrap as a starting point for CSS. Some applications will be heavier on the Web API code than the MVC code, but that all depends on the type of app. I think it is also reasonable for people to use ASP.NET Web Forms or Web Matrix, if that's what they like and it solves the problem for them, they just aren't technologies that I enjoy working in every minute of the day. The middle layers are all C#, although I think F# would benefit some of the stuff I've built in the last 4 years. The data store is a bit tricky and again depends on the application. I'm looking at using MongoDB (again) for a project, if everyone else buys in on it. RavenDB is also an excellent choice for a document database. If I was using SQL Server I'd have to decide between EF and a lightweight ORM like Simple.Data or Massive. For many services a stateful ORM is a bit of overkill, I don't need to track changes just map properties to columns, and the lightweight frameworks make this easy. Hope that helps.
Gravatar Tuyen Nguyen Thursday, February 28, 2013
Thank you Scott.
Comments are closed.