> From personal experience .... I can't comment on ASP.NET MVC
Then you don't have personal experience in the area of Scalable web-based systems based on .Net. I speak from personal experience.
You don't need to go near EF, there are plenty of other ways to access data, the lightest of which is Plain Old SqlConnection. Don't knock it when you have a few simple, well-defined queries.
Though you should also look at other open-source lightweight frameworks such as Nancy or ServiceStack.
Also, it helps to use more loosely coupled components on merit not source language. It doesn't matter that ZeroMQ, RabbitMQ, memcacheD or StatsD aren't coded in .Net, it just matters that you can connect to them.
>> From personal experience .... I can't comment on ASP.NET MVC
>Then you don't have personal experience in the area of Scalable web-based systems based on .Net. I speak from personal experience.
Why? I've played with it and it felt kind of heavy and over-engineered, though the high-level APIs are usually what gets pushed the most. I've never needed to spend a significant amount of time scaling anything built on ASP.NET MVC, hence the comment. If there's some exceptional properties that recent versions have developed I'd love to hear about them but in general I avoid it because of the perceived heaviness.
PS I'm not suggesting that doing traditional ASP or ASP.NET dev is where it's at for scalability, my experience comes from working on frameworks that largely bypassed all of that.
> I've played with it (ASP MVC) and it felt kind of heavy and over-engineered,
Compared to what? Webforms? definitely not, MVC is generally faster at serving pages, and pushes the coder towards less coupled, more testable code.
Though with MVC the key concepts are right there in your face - you need to deal with routes, controllers and views before you get anything showing up in the browser, but the alignment with the way the web actually works is much better than with webforms.
The complexity shows up later with webforms, Once you work with webforms a lot the impedance mismatch and the leaky abstraction extinguish the notion that Webforms is lightweight or right-engineered. viewstate. Did you ever try to memorise the page event lifecycle http://msdn.microsoft.com/en-us/library/ms178472%28VS.100%29... , yeesh! And that complexity is nothing more than an artefact of the framework, all with runtime overhead.
Not so with MVC, once you get comfortable with the concepts, it keeps on giving. It plays well with http, a stateless protcol. And that's where scaling comes in, by playing well with http.
Compared to a lightweight REST API framework like ServiceStack or Nancy, MVC is somewhat heavier. But if you're using those well for REST data microservices then I'm not going to criticise your choices, keep right on at it.
I agree that webforms is bad. I worked on the framework side of things before ASP.NET MVC was an option and needing to roll our own was where most of my experience scaling .NET systems has come from. In spite of that, .NET was a good choice for other reasons and was fun to build and scale.
Then you don't have personal experience in the area of Scalable web-based systems based on .Net. I speak from personal experience.
You don't need to go near EF, there are plenty of other ways to access data, the lightest of which is Plain Old SqlConnection. Don't knock it when you have a few simple, well-defined queries.
Though you should also look at other open-source lightweight frameworks such as Nancy or ServiceStack.
Also, it helps to use more loosely coupled components on merit not source language. It doesn't matter that ZeroMQ, RabbitMQ, memcacheD or StatsD aren't coded in .Net, it just matters that you can connect to them.