4 ms·

From personal experience, the higher-level features and frameworks that MS puts out for .NET are what tend to get in the way of successfully scaling .NET system

by bchjam 13y ago

From personal experience, the higher-level features and frameworks that MS puts out for .NET are what tend to get in the way of successfully scaling .NET systems. I can't comment on ASP.NET MVC but I don't trust EF at all, and even the higher level XML interfaces can be problematic. Basically it comes down to profiling and optimizing, just like in any other system. Just don't design your systems to be tightly coupled to any particular API. If I were building a new system in .NET I'd base it off of open source tools that weren't available when the systems I currently work on were built. The most appealing of these seem to be built by stackexchange folks at the moment (ie servicestack, dapper). These tools were designed to be Mono-friendly and deploy to Linux so less licensing/vendor lockin worries. In general I don't trust MS but I do like .NET and often turn to F# for personal projects.

SideburnsOfDoom 13y ago
> 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.
- bchjam 13y ago
  >> 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. (edited for clarity)
  - SideburnsOfDoom 13y ago
    > 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.aspx 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.
    - bchjam 13y ago
      Thanks, that makes much more sense. 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.

by bchjam 13y ago

SideburnsOfDoom 13y ago

> 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.

bchjam 13y ago
>> 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. (edited for clarity)
- SideburnsOfDoom 13y ago
  > 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.aspx 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.
  - bchjam 13y ago
    Thanks, that makes much more sense. 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.