[spongle]

Sorry signed up to say this - been lurking a while but this one infuriated me terribly.

The only reason ASP.Net MVC looks good is because you were a WebForms user before. If you've come from other tech, it's still a stinking pile of crap.

1. The API is totally broken and consists of tonnes of barely testable wrappers (HttpResponseWrapper etc).

2. The attribute model is a pain in the arse. How do you test filters based on attributes effectively?

3. Razor is horrible. I mean really horrible. The semantic difference between inline C# code and JS/HTML is so weak that you end up having to hint the view engine as to what is what. Not only that, the Layout system it uses basically stuffs RAM full of string buffers. If you have a complicated page and thousands of users (like we do), memory goes sky high. Please give me something like Jinja2.

4. The ASP.Net pipeline isn't thread safe at all. It's scary actually. You can't guarantee one module won't set global thread state on another thread. This only happens under heavy load. That is one absolute fucker to debug.

5. MS11-100 broke absolutely fucking everything from downloading Excel files in IE8 and below over SSL, knackering caching etc. This is the norm. Stuff just does this all the time. One day it works, next it doesn't.

Now I could spend all day writing this list but I'll surmise it as the whole .Net (web stack) is a stinking shit crock which pains me every day I have to use it.

I LONG for the days someone will hire me based on other skillsets but the market is saturated with people who thought it was a great idea and are stuck with it now.

(For ref the .net desktop / WPF stuff is wonderful in comparison, apart from Visual Studio which crashes on me so often it's just ugh..).

[efdee]

I like to think of myself as a polyglot programmer and I can't help but disagree with your statement that ASP.NET MVC only looks good because Webforms is so horrible.

1. I am not sure why you have problems testing the wrapper classes. I can't say I've encountered issues unit testing my controllers or other MVC specific components.

2. You test the attributes themselves as you would test any other class. Eg you test that OnActionExecuting etc yield the correct results. On your controller, you just need to test for the presence of the attribute, since you already know that it works as advertised.

3. I cannot comment on your claim about the Layout system, but I have absolutely no idea what you mean with the 'having to hint the view engine'. You need to tell it which parts are inline code, and those parts should be C#. Razor has no interest in your JavaScript code.

4 and 5, again, can't comment on these since I haven't encountered them, even though I worked on a number of sites that had moments of extreme high load. In addition, I have found that the number of 'stuff that just breaks' is minor compared to what I've seen in other frameworks. Sometimes things go wrong, but it really is not as dire as you portray it.

My 2 cents, YMMV.

[rjbwork]

I much prefer working in .NET MVC4 than I did trying the same pattern in Java with JSP/Servlet/Spring. Things seem to just work.

As for 1, I haven't really had to write tests around these wrappers yet.

I can't really comment on 2 as we don't use but a couple of pretty simple ones that ARE easily testable.

I'm also really not sure what you mean with 3. If by "hint" you mean use @ as your denotation for C# code, then yeah, I guess you do. I also don't see how it's much different from Rails templates, and in fact I think the syntax is far more readable than rails templates (disclosure: I've not used Rails extensively or professionally) and a marked improvement over JSP/ASP Classic.

4. We've got >20k users who access the site multiple times a day and we've not seen anything indicating thread corruption. Not saying you're wrong, but I'm really not entirely sure what you're talking about, perhaps you could elaborate?

5. I can't really comment on this one either, but I can say for a fact that we currently have users downloading excel files over SSL in IE8 and greater.

[edwinnathaniel]

Maybe you should update your Java skill? Servlet/JSP vs MVC4? Try SpringMVC and JAX-RS.

I've ben going back and forth between Java and C# in the not-so-distant past and I felt that C# ecosystem is just too limited.

[rjbwork]

I mentioned Spring. It's been a couple of years, but doesn't Spring's MVC pattern use JSP for the view templates?

[edwinnathaniel]

JSP is just a tiny part of the whole stack no? You're free to develop single-page app using whatever your choice of JS frameworks.

I believe any Spring view plumbering can process several java-based templating languages (Velocity, JSP, JSF, etc).

You did mentioned Spring but in the same breadth with Servlet+JSP which makes me wonder if you're just using Spring-core and not the more modern stuff.

Keep in mind that there's now "flow" based solution in .NET world. "Flow", while it is not the best choice for the whole presentation stack, has it values for developing wizard-like/shopping cart section of your app.

[narshe]

I think your issues are the reason there are other alternative frameworks that have come out; and there are a lot of them. Use one of the alternative .NET web frameworks if you don't like MVC proper.

I'm not a fan a Razor either. It's code-centric instead of html-centric. Again, use an alternative view engine like Spark. I think a better recommendation is DON'T PUT LOGIC INTO YOUR VIEWS. You will rarely run into issues if you follow that.

Any issues I've found I have also found fixes for relatively easily. If you run into something that is a framework bug that you can't fix, call up MS and they will issue you a patch that fixes the problem you're having. MS has great support, so don't be afraid to use it.

[pmarsh]

What extensions are you using with Visual Studio? Found vanilla to be really stable, but certain extensions result in some random crashes. But not terribly often.

[spongle]

None whatsoever. We killed R# and VisualSVN. Do without the former and use TSVN for the latter.

We have 34 projects loaded in the solution so it hits VS's limited 32-bit process restrictions pretty quickly causing the debugger to break miserably. When this fails it's a restart job.

[narshe]

What do you need 34 assemblies for? Seriously?

[spongle]

Our product is very non-trivial! That's just one deployable endpoint. We have 131 projects in total.

some of our application silos are more complicated than other companies entire businesses are. One subsystem has 450,000 LOC in just c# alone and the domain model has 122 classes.

Stuff gets complicated in some sectors...

[narshe]

I understand the complexity issue, and how large corps deal with that stuff... There are other ways you can chunk that stuff up though. Maybe you don't have a choice.

I don't think you can fault Visual Studio for not handling that many projects well.

[spongle]

Agree but we don't have much of a choice. The cost and risk associated with cleaning it up is actually more expensive than leaving it.

Visual Studio would do fine if it was a 64-bit binary. The memory ceiling of 32-bit processes is the problem. People have been calling for 64-bit Visual Studio for a long time.

That is their fault.

[Touche]

Ditto on Razor. It's like 2002 php. Except you can't really create reusable partials because of static typing. Sure, you can just make everything dynamic, but then the top of your view turns into:

   @{
     /* A bunch of repetitive object creation and casting */
   }

Which has happened in every razor project I've seen anyways.

[efdee]

Object creation and casting in side your views? Maybe you are just putting too much logic in your view. Use interfaces as your model for partial views and reuse becomes a no brainier.

[railsfan]

Sorry, signed up to say that you sound like an angry young developer. It sounds like you're angry that you're being "forced" to use a tool you have no idea how to use. I use many different development frameworks and have even used Visual Studio. It's not my main development environment but even I know enough not to load 34 projects into a single solution. Ever hear of compiling some of them and referencing the binaries? What a cluster your code must be.

[rnbennett]

You assume too much - disappointing. I was in the .NET world for 12-13 years and worked for MS at one point. I was hardly being 'forced' to use it - instead I was regularly brought in to come in and fix / re-architect others' awful messes.

We both know it's not right to load 34 projects into a solution. It's not something I'd ever do, but it's done by many. I saw it commonly in my clients. My last .NET project I took on about 18 months ago, my client had a Classic ASP/2.0/3.5 chimaera with 50+ solutions, each with up to 40 projects in each. DataSets calling SQL Server stored procs for a data layer. The build process took almost an hour.

It's common unfortunately. Big enterprise, old platform, cluster of code. I stopped using .NET because those enterprises have no desire to fix it.

[spongle]

Which is what I'm stuck with (I'm not junior staff either btw - been doing this lark for 26 years). We don't load all the projects at once.

This is actually the debugger failing to load all the symbols into the vshost process because of the memory ceiling being 3.5Gb for 32-bit processes rather than the IDE failing itself. Unfortunately due to poor isolation in VS, it takes out IIS Express and VS IDE.

Release binaries don't blow it but debug ones with pdbs do. This is a shit when your project is large with long dependency chains.