<story><title>A todo list for new ASP.NET Core projects</title><url>https://biarity.gitlab.io/2018/02/08/asp-net-core-todo</url></story><parent_chain><item><author>jasonkester</author><text>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.&lt;p&gt;In the old days, that meant you could toss out all silly drag&amp;#x2F;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 &lt;i&gt;called&lt;/i&gt; MVC that wasn&amp;#x27;t as good at it).  Now it means that I can read this list and not see a single technology I&amp;#x27;ve touched at all in my 18 years of build stuff on this stack.&lt;p&gt;Personally, I tend to disagree with the author&amp;#x27;s approach of pushing routine stuff out to the realm of &amp;quot;magically happens behind the scenes&amp;quot;, 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.&lt;p&gt;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.&lt;p&gt;But again, it&amp;#x27;s cool that the stack gives us the option to do so if it fits our style.</text></item></parent_chain><comment><author>cptskippy</author><text>&amp;gt; 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.&lt;p&gt;I feel the same way as you however I&amp;#x27;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&amp;#x27;s often easier to just wire up all of the important parts behind the scenes.&lt;p&gt;It&amp;#x27;s also useful when you&amp;#x27;re managing a number of projects that are primarily maintained by junior developers and you only drop in occasionally to do the heavy lifting.</text></comment>
<story><title>A todo list for new ASP.NET Core projects</title><url>https://biarity.gitlab.io/2018/02/08/asp-net-core-todo</url></story><parent_chain><item><author>jasonkester</author><text>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.&lt;p&gt;In the old days, that meant you could toss out all silly drag&amp;#x2F;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 &lt;i&gt;called&lt;/i&gt; MVC that wasn&amp;#x27;t as good at it).  Now it means that I can read this list and not see a single technology I&amp;#x27;ve touched at all in my 18 years of build stuff on this stack.&lt;p&gt;Personally, I tend to disagree with the author&amp;#x27;s approach of pushing routine stuff out to the realm of &amp;quot;magically happens behind the scenes&amp;quot;, 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.&lt;p&gt;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.&lt;p&gt;But again, it&amp;#x27;s cool that the stack gives us the option to do so if it fits our style.</text></item></parent_chain><comment><author>pc86</author><text>&amp;gt; &lt;i&gt;I tend to disagree with the author&amp;#x27;s approach of pushing routine stuff out to the realm of &amp;quot;magically happens behind the scenes&amp;quot;&lt;/i&gt;&lt;p&gt;Me too, and it&amp;#x27;s easy to take this approach &lt;i&gt;way&lt;/i&gt; too far to where you&amp;#x27;re basically recreating your own MVC architecture in some pseudo-service layer that you&amp;#x27;re not 100% sure how it even gets executed in the first place.&lt;p&gt;But I&amp;#x27;ll admit for things you should be doing on 99.9% of calls (e.g. validating the model) it&amp;#x27;s nice to have it done one place and one place only.</text></comment>