5 ms·

One of the cool things about ASP.NET is how many different ways there are to get things done. There is a ton of stuff in there, and you can pick and choose the

One of the cool things about ASP.NET is how many different ways there are to get things done. There is a ton of stuff in there, and you can pick and choose the bits that make sense for your project. In the old days, that meant you could toss out all silly drag/drop, faux-stateful garbage they put in to make it so you could build webapps like they were VB6. Thus, leaving behind a really good compact MVC framework for building webapps (long before they came out with something actually called MVC that wasn't as good at it). Now it means that I can read this list and not see a single technology I've touched at all in my 18 years of build stuff on this stack. Personally, I tend to disagree with the author's approach of pushing routine stuff out to the realm of "magically happens behind the scenes", in favor of having common base classes for my page handlers that can be explicitly told to do those things with a little Initialize() method at the top of the handler. That way, when something goes wrong I get a breakpoint looking at my own code. I like control, so the idea of voluntarily putting something in place that could magically shove its way in front of my code and whisk the user off to an error page just smells wrong. But again, it's cool that the stack gives us the option to do so if it fits our style.

mattmanser 9y ago
I do feel the recent changes have moved to prescription rather than flexibiity though. For example, last I looked, the new configuration manager has to be injected. Injected! To me, who's not a particular fan of injection, that's insane. Especially given that the previous iteration was a static class that most of would just wrap in a static class called something like "Constants" or something. These are global, static, variables. They shouldn't be changing during the application's run-time It should be super simple to use and fire-and-forget. Having to pass it into every constructor and then manage it is crazy to me. Yeah, you can wrap the whole thing yourself, but it's just been done because DI is trendy at the moment. In my opinion, for a statically typed language, DI is just a pretty nasty language hack that's only there to facilitate test methods. You shouldn't be designing things around it.
- pc86 9y ago
  Serious question: how do you test something without injection? But yes I agree injecting configuration seems sub-optimal at best.
  - PerfectElement 9y ago
    In the case of the configuration manager, the test project would have its own underlying configuration file.
  - mattmanser 9y ago
    Read about Ruby and DHH's opinion on DI. That's how. Also, remember there's a huge swathe of apps where tests are wholly inappropriate and designing everything around DI is annoying for all those cases. Prototypes, one time apps, internal tasks, the significant proportion of programmers who think testing's a waste of time and/or money, etc. or that only small, key parts should be tested.
- Wolfspirit 9y ago
  I'm not quite sure what you mean. There is no ConfigurationManager used in Asp.NET Core. Are you talking about IConfiguration? The reason why you want to have it injected as IOption<> is cause you might want to change configuration on the fly. If you do it right, there is no need for the app to restart if you change the appsettings.json at all. Also it makes things much more flexible and loosely coupled, for example third party middlewares can bring their own Settings and you can define which part of the whole appsettings.json is meant to be for that Middleware. There is also no need to pass it to the constructor and manage it yourself via a field inside your class, at least in your controllers. You can just use the [FromServices] attribute before an action argument to inject it into just that method (and that works for properties deeper down the "callstack" aswell).
  - mattmanser 9y ago
    Sigh. Of course I want the app to restart, it's configuration. Changing it on the fly and hoping the Devs coded defensively enough to handle mutating config is a recipe for disaster. I can see a case for mutable config, I use it, but the majority of config is not app time mutable and you shouldn't be designing a system for an edge case. Have a mutable config. Experienced devs use the db for that by the way as mutable config generally needs an in app interface.
pc86 9y ago
> I tend to disagree with the author's approach of pushing routine stuff out to the realm of "magically happens behind the scenes" Me too, and it's easy to take this approach way too far to where you're basically recreating your own MVC architecture in some pseudo-service layer that you're not 100% sure how it even gets executed in the first place. But I'll admit for things you should be doing on 99.9% of calls (e.g. validating the model) it's nice to have it done one place and one place only.
- DougWebb 9y ago
  The drawback to validating the model in one place only, as shown, is that there is only one response for validation errors. Sure, it's got the details of the error that will vary, but it's ALWAYS sending a 400 error. Even the example of the 'usual' way includes a comment showing multiple possible responses: // return bad request, add errors, or redirect somewhere An ActionFilterAttribute might be a good approach, but in a real application I'd want two things: to apply it explicitly at the controller or method level rather than globally, and to pass it arguments to tell it what to do when there is an error. One of the arguments should allow me to call a response handler method, even if the only way to do that is to pass a string with the method name and use reflection to find and invoke it.
nu5500 9y ago
I remember fondly "back in the old days" spending a couple of years doing Java servlets (for reference, this was right when JSPs were becoming a thing) where we implemented a nice compact MVC approach. The performance was very good at the time. When I moved over to ASP.NET I felt baffled by all of the heavy WebForms templating, but soon discovered that you could set up an almost identical framework as we had with servlets by implementing HttpHandlers and some light-weight views with all the ViewState stuff turned off (it was probably most similar to something like NancyFx now). I feel like many of the frameworks now are doing the same stuff that worked well 15 years ago, but it is fleshed out better. And of course there is a ton of open-source work, which was missing back then.
weego 9y ago
interestingly the plus points from your first sentence (which I agree are plus points) are the exact things that Scala is often criticised for.
cptskippy 9y ago
> I like control, so the idea of voluntarily putting something in place that could magically shove its way in front of my code and whisk the user off to an error page just smells wrong. I feel the same way as you however I've found that when working on a large code base with a lot of junior developers or contractors who lack qualities like discipline, attention to detail, consistency, and convention; it's often easier to just wire up all of the important parts behind the scenes. It's also useful when you're managing a number of projects that are primarily maintained by junior developers and you only drop in occasionally to do the heavy lifting.

mattmanser 9y ago

I do feel the recent changes have moved to prescription rather than flexibiity though. For example, last I looked, the new configuration manager has to be injected. Injected! To me, who's not a particular fan of injection, that's insane. Especially given that the previous iteration was a static class that most of would just wrap in a static class called something like "Constants" or something. These are global, static, variables. They shouldn't be changing during the application's run-time It should be super simple to use and fire-and-forget. Having to pass it into every constructor and then manage it is crazy to me. Yeah, you can wrap the whole thing yourself, but it's just been done because DI is trendy at the moment. In my opinion, for a statically typed language, DI is just a pretty nasty language hack that's only there to facilitate test methods. You shouldn't be designing things around it.

pc86 9y ago
Serious question: how do you test something without injection? But yes I agree injecting configuration seems sub-optimal at best.
- PerfectElement 9y ago
  In the case of the configuration manager, the test project would have its own underlying configuration file.
- mattmanser 9y ago
  Read about Ruby and DHH's opinion on DI. That's how. Also, remember there's a huge swathe of apps where tests are wholly inappropriate and designing everything around DI is annoying for all those cases. Prototypes, one time apps, internal tasks, the significant proportion of programmers who think testing's a waste of time and/or money, etc. or that only small, key parts should be tested.
Wolfspirit 9y ago
I'm not quite sure what you mean. There is no ConfigurationManager used in Asp.NET Core. Are you talking about IConfiguration? The reason why you want to have it injected as IOption<> is cause you might want to change configuration on the fly. If you do it right, there is no need for the app to restart if you change the appsettings.json at all. Also it makes things much more flexible and loosely coupled, for example third party middlewares can bring their own Settings and you can define which part of the whole appsettings.json is meant to be for that Middleware. There is also no need to pass it to the constructor and manage it yourself via a field inside your class, at least in your controllers. You can just use the [FromServices] attribute before an action argument to inject it into just that method (and that works for properties deeper down the "callstack" aswell).
- mattmanser 9y ago
  Sigh. Of course I want the app to restart, it's configuration. Changing it on the fly and hoping the Devs coded defensively enough to handle mutating config is a recipe for disaster. I can see a case for mutable config, I use it, but the majority of config is not app time mutable and you shouldn't be designing a system for an edge case. Have a mutable config. Experienced devs use the db for that by the way as mutable config generally needs an in app interface.

pc86 9y ago

> I tend to disagree with the author's approach of pushing routine stuff out to the realm of "magically happens behind the scenes" Me too, and it's easy to take this approach way too far to where you're basically recreating your own MVC architecture in some pseudo-service layer that you're not 100% sure how it even gets executed in the first place. But I'll admit for things you should be doing on 99.9% of calls (e.g. validating the model) it's nice to have it done one place and one place only.

DougWebb 9y ago
The drawback to validating the model in one place only, as shown, is that there is only one response for validation errors. Sure, it's got the details of the error that will vary, but it's ALWAYS sending a 400 error. Even the example of the 'usual' way includes a comment showing multiple possible responses: // return bad request, add errors, or redirect somewhere An ActionFilterAttribute might be a good approach, but in a real application I'd want two things: to apply it explicitly at the controller or method level rather than globally, and to pass it arguments to tell it what to do when there is an error. One of the arguments should allow me to call a response handler method, even if the only way to do that is to pass a string with the method name and use reflection to find and invoke it.

nu5500 9y ago

I remember fondly "back in the old days" spending a couple of years doing Java servlets (for reference, this was right when JSPs were becoming a thing) where we implemented a nice compact MVC approach. The performance was very good at the time. When I moved over to ASP.NET I felt baffled by all of the heavy WebForms templating, but soon discovered that you could set up an almost identical framework as we had with servlets by implementing HttpHandlers and some light-weight views with all the ViewState stuff turned off (it was probably most similar to something like NancyFx now). I feel like many of the frameworks now are doing the same stuff that worked well 15 years ago, but it is fleshed out better. And of course there is a ton of open-source work, which was missing back then.

weego 9y ago

interestingly the plus points from your first sentence (which I agree are plus points) are the exact things that Scala is often criticised for.

cptskippy 9y ago

> I like control, so the idea of voluntarily putting something in place that could magically shove its way in front of my code and whisk the user off to an error page just smells wrong. I feel the same way as you however I've found that when working on a large code base with a lot of junior developers or contractors who lack qualities like discipline, attention to detail, consistency, and convention; it's often easier to just wire up all of the important parts behind the scenes. It's also useful when you're managing a number of projects that are primarily maintained by junior developers and you only drop in occasionally to do the heavy lifting.