Is this an ASP.NET Core I see before me? Where to next for Microsoft's confusing web framework... Microsoft's ASP.NET Core, a web application framework (or more accurately, a family of frameworks), has made strides in performance and innovation, but its rapid development has resulted in a bewildering range of choices facing developers. The original ASP.NET was launched simultaneously with .NET itself, way back in 2002, co- …
I think as with any language when looking in from the outside the bewildering options (which they are options) can discourage a few, but come on look at Java
As a .NET dev for many years coming from the original ASP set, there was a few years where everything was confusing but now its pretty obvious
.NET Core (which is now just .NET) is the way to go for all new developments
In fact it has only got clearer as a developer in the .NET family
.NET Core (which is now just .NET) is the way to go for all new developments
It must be nice to work somewhere that you only have to think about new developments. During the lifetime of our current project (not yet released after three years) there have been two significant changes to .NET and we've had to port our solutions twice in order to stay current - we've still yet to move some projects over to .NET Core. I've been developing for .NET for nearly 15 years now and it seems to get more confusing every year.
Not just the number of framework versions that you have to understand (and the various bodges needed over the years - remember the BCL bodge for async/await?) but also the different ways that the tools work (references are handled differently for .NET Core). How many iterations of Nuget package managing has VS gone through now? Is it four, five?
If .NET Core hangs around long enough it will start to simplify things but those of us with several years of projects to support are going to have to keep struggling through the confusion. I don't say it's a huge problem but trying to pretend that it isn't a problem is hiding an uncomfortable truth.
Did you miss the bit when I said it hadn't been released yet? I mean, sure, we could ship it (hopefully this year) still targeting .NET 4.5 but it's hardly an auspicious beginning for an application suite with an expected life time of a decade. It also doesn't help our team if we prevent them using new technology while working on new developments. Would you be happy to work on a new project that was targeting .NET 4.5 as part of a team where no-one had any practical knowledge of Core?
The project is still under development so we want to be using the latest tools and latest framework. We also want our team members to be up to date with developments so that we remain competitive and retain staff.
Our existing applications, sure, they pretty much stay where they are although we had to upgrade them to .NET 4.7 in order to get TLS1.2.
Na I don't just develop new projects I still work with web forms on a daily basis
But I make very good arguments for porting what we can
If management are a no go maybe the problem is you haven't argued your point well enough re security etc
Maybe you just work in a place where development is seen as a sink hole
Thankfully I don't for once (I have 15+ years myself)
At the end of the day it is clear what the path forward is and if you can't make arguments for the push forward maybe that's on you maybe that's on management
My argument was that it is clearer than it has ever been
Your argument makes no sense to my original post
I think that's part of the problem.
Write some code - and the database gets created for you. Take a database and the code gets automatically generated. Make changes and the code and the data are automatically synchronised. Now, to be fair, this has had to be simplified a bit for Core, but the more ways there are to do something, the harder it is to document and the more developers get confused about what's actually going on. Generally, I'd rather do a bit more work up front and be confident about what was happening behind the scenes - and that it wouldn't be deprecated or significantly amended in the next release.
Yup, I call it implicit code (or sometimes automagical). It can save a huge amount of time and effort but one day when you least expect it your magical black box stops working and then good luck trying to fix it. Maybe you get an arcane error message but mostly you just have to hope someone else has encountered the problem and has a fix. Failing that you can only hack around in the hope of stumbling onto the magic incantation that gets it all working again.
I'm not sure what you guys are referring to.
I remember the pre-EF and pre-SSDT days. Our team had way more support incidents with half-baked database schema updates and SQL injection bugs galore.
I welcome any tool that automates the boring bits that all too often goes haywire because in the end they are just boring.
And hey, when using commonly used tools, at least you aren't slugging at it alone. There is, as you point out, a good chance somebody have tripped over similar issues. Using home-brewed solutions: Zero chance.
I've never used EF, but I did once take over maintenance for a mess of a project which used NHibernate in some parts and some third party code generation tool whose name I forget in others. And direct SqlCommand access to views which were 200 lines long and full of subqueries on the admin side. In some ways the third party tool was the best: sure, it was a pain in the arse to use, but it avoided the black box problem because when I really got fed up with some aspects of the code it was generating I could edit the templates. (Some kind of VBA, I think. I never found out exactly, but it's not the only time I've had to maintain code in a language I didn't know. Eventually I figured out how to make the tool use C#, and rewrote the templates from scratch).
Microsoft is throwing Web Forms developers under the bus and refuses to move it forward from .NET Framework to .NET Core. I could live with having to run it on Windows. However, the problem is that .NET Framework lacks new language-level support. .NET Framework doesn't support .NET Standard 2.1 which EF Core 5 now requires. This means that you won't be able to use the latest EF Core with Web Forms applications. EF Core has had a lot of problems over the years. Problems with the query engine. Slow performance. Missing features that were in the original EF. etc. Web Forms needs to be brought forward. There are a lot of Web Forms apps out there and they aren't going to get re-written. Especially, when the newer technologies don't do what it does. Server-side Blazor is probably as close as it gets to a replacement, but, it is still immature. Also, I cannot stand the design of post Web Forms ASP.NET. It was easier to use in the old days. Personally, I am not happy at all with what Microsoft is doing with web development. Microsoft shouldn't be so quick to throw their loyal developers under the bus considering the new developers seem uninterested in their products based on the results of the StackOverflow survey. Not happy at all.
From my perspective it feels like it's going the other way - on Core they're starting to talk people out of MVC and into Razor Pages, which is closer in approach to WebForms.
That puts me off personally, I migrated a big e-commerce site from WebForms to MVC years ago and it was a real transformation, I have lots of time for MVC.
They need to have good options for server-side pages because Node doesn't, I've messed about with a few view engines on express and they're not a patch on Razor.
WebForms needs to die. I'd say a slow and painful death but it's already doing that so a quick death instead please! What needs to happen is for EF Core to be fixed so that it is actually a viable alternative to EF or writing your own data layer.
"Isn't that what .NET 5.0 is?"
No it isn't. .NET 5 is .NET Core. It was going to be .NET Core 4. But, Microsoft decided to rename it so not to confuse it with .NET Framework 4.x.
But it will confuse the hell out of developers when their Framework project is moved to .NET 5 and there are a ton of breaking changes.
Not all the confusion is down to Microsoft. There are three major causes. Firstly there was WHATWG and HTML5. This supposedly made the browser a more standard platform for applications but introduced the living document approach to defining HTML5 and broke the existing delivery of HTML by apps. Now the browser defines the application delivery more than Microsoft. Secondly, there is Open Source and the move towards Linux away from Windows. This limits further what the application technology can do. Then, thirdly, there is the move towards Social Media. This again took the initiative away from Microsoft as companies behind social media drove the technology more than Microsoft. So all three factors are about loss of lead by Microsoft and particularly about Google gaining prominence. This has surely made the water a little muddier for developers but the payoffs might well compensate them.
I'll be honest I quite liked WebForms, and I still do... seemed sensible, much better than legacy ASP. and the MVC incarnation - seemed a bit sledgehammer/nut
Strangely enough, I just couldn't get to like ASP.NET MVC - it seemed clunky, debugging seemed a PITA to me - maybe I was just to used to WebForms. When I had some time between roles, to sit down and properly use MVC, I still didn't like it. I know what it was trying to achieve, but ultimately it still didn't give me anything I couldn't do with WebForms - there was for me - no killer feature - and dev seemed slower
Yes, you had a separation of concerns but at the end of the day - if you are a small shop, the SOC doesn't really give you much was the general opinion. Point taken with viewstate, which was always a hacky method, and if you LB'd servers, you stored in SQL itself, or used something like StateMirror, but ut worked and actually improved sloppy coding - you soon noticed what you were storing in it wasn't necessary.
Now, I don't do front-end stuff in web, and I don't miss any of it..
Trying to disentangle the hellscape of nested selects and correlated subqueries that EF creates to figure out what it's actually trying to do, and turn it from a 4000ms horror that requires 30% of the system's entire resources to a sub millisecond query that you can show to a developer and say 'make it do that', only to be told it can't makes EF the bane of the lives of anyone who has to tend a database that's been around for more than a couple of years. EF looks like not merely a marketing tool for SQL Server, but a means of ensuring that the number of licenses required to run a given database is increased by orders of magnitude, and the costs of running a database with more licenses than it needs for years is likely to outstrip the cost of teaching developers how to write a decently optimized bit of SQL.
I suspect that the developers who use EF are long gone by the time someone operations realizes that the business is being bankrupted by their database and some poor DBA is told it needs to be looked into.
EF was always handy for prototyping, EF Core is - though I personally am still suspicious about it in many cases - pretty much production ready. As long as you you understand what it's doing, how expression trees work and you're comfortable with ExecuteSqlRaw(sqlstring) when necessary. It's come a long way, although I admit that the singleton thread-unsafe context is infuriating at times.
However, I strong agree with the article that making every last ASP.NET sample, document and tutorial use EF Core is unnecessary, a barrier to entry where you don't know it or your shop doesn't use it and smacks of upselling, which is distasteful.
B- needs work.
I had this argument (I argued from your side) with another developer on a project I started 3 years ago. I recounted the horror stories of projects being sunk by EF, and we agreed that there was no way we'd use it for anything but SELECT. I still felt that it would do as you say and generate poorly performing SQL. We agreed that when I could demonstrate it was doing that despite well formed linq queries, we could move to procs. Three years later I have accepted I lost that argument. It does create a crazy amount of nested subqueries with curious renaming of columns from C1 to C2 and vice-versa, and it makes liberal use of cross and outer apply statements. However everytime I look into it and throw in a simpler query, the actual execution plan that SQL server generates is the same. Now we do have a fairly simple schema, it's just your basic joins, aggregates and groupings. I would still say that I have observed that the apparently crazy SQL generated by EF is actually just as efficient under the hood.
If you have some direct examples of linq queries generating worse execution plans than the SQL you could write, I expect it would be useful to publish them somewhere. The EF core team will probably want to review it.
Very much this.
On many projects I've been brought into to help improve performance related to data access, where I'm told "It's because of stupid EF". And then I've discovered that 90% of the problems are caused by missing indexes on tables, or by developers assuming that EF is somehow able to magically translate their terrible N+1 loops into fast queries, and fixing that solves most of the problems. i.e. even if they had used direct SQL the problem would have been the same because they were doing the classic mistake of reading header records and then looping through and reading related tables for each header, classc RBAR cock-up.
With the exception of edge cases where performance really does need to be hand-tweaked (and frankly I could count on one hand the number of times I have come across one of these, even really fast bulk insert is possible these days with EF), I've found EF (both core and non-core) to be an excellent solution for data access, it saves a ton of manual and error-prone data mapping, and in the handful of cases where it really isn't suitable to have your SQL generated for you, you can just point it at a View in your database and forget about it, or use Dapper, etc, if you really need to squeeze a little more performance.
It is kind of annoying how this "EF sucks, NHibernate sucks, ORMs are stupid" myth keeps doing the rounds, seeing ridiculous amounts of time wasted on what amounts to artisan, hand-coded data access layers ridden with defects. I can't remember who said it but I do believe that "Writing your own Data access code is stealing from your customers" to be quite apt here. One suspects that in the vase majority of cases including my own (admittedly anecdotal) experiences that the real problem is that the developer's ability to understand and implement a performant database system is what actually sucks :)
Increasingly, being a programmer is more about devops than writing code.
What I mean is that the insane proliferation of platforms, libraries, widgets, protocols, languages and architecture options means that you spend far more time fiddling around with versions of things, packaging, buzzwords and keeping stuff current than you used to.
I don't like it one bit. Writing code is an entirely separate intellectual skill from collecting libraries and buzzwords.
A comment I can totally agree with. Last year I decided to pick up ASP.NET and use the MVC format since I was told Forms was old hat. I then find out that most folk in the company dont use MVC and prefer Forms, Im a newbie when it comes to MVC so dont get angry if the last part sounds sh1t :). I like the principle of MVC, a structured approach, since the Forms apps I looked at seemed all over the place and you needed bespoke knowledge of the application to make sense of it
On my learning curve for MVC the array of stuff to memories seemed bewildering its not just code. I have written loads of stuff with C#, small scale things, but MVC seems to demand a vast amount of knowledge on e.g. libraries, release versions of .NET.
The company I work for only has Visual Studio 2015 and I have no idea when they will move onto 2019. Its such a difficult position to manage i.e. do I stick with MVC or move onto CORE and wait for the company to upgrade. Also I thought EF was a brilliant addition, once I discovered it, but it seems its a pile of sh1t, but for someone who has not developed in-depth MVC apps it saves a lot of typing.
Apart from Garlic Bread* what is the future. It always seems a mix of opinions from mid range developer to expert in-depth developer and never the twain seem to match.
*Peter Kay - Phoenix Nights reference
I love the fact it's open sourced. I've built ASP.NET Core and used the debug assemblies whilst developing apps. It's great for understanding why things aren't working especially around routing.
Rant Time:
Regarding EF Core I've used it for quite some time now (forced to) and have to say it's been a pain especially version 2.X which had serious bugs / issues..I find migrations OK for small apps but for larger ones creating snapshots with thousands of lines of code per migration leaves an unpleasant taste in ones mouth.
I would have been happy using something simple like Dapper ORM, but the old snake of oil of "oh yes but we can just switch database engines seamlessly", comes out when the powers that be decide what to use...Never mind that Linq queries are translated at the provider level with no guarantee that they will work across Db Engines. The queries that are produced can be unpleasant to read as well.
Leave it to Microsoft to always be late to the party and show up stumbling drunk.
Filemaker has been fully integrated for years. Scale-able, easy to get started. Can be as simple or complex as you need. Website front ends in a jiffy, easily linked to your DB and easy to spin up applications. Small businesses and webmasters can get up and running just on templates alone that look and work good.
No, I don't work for Filemaker, but I do loathe Microsoft. This is just another reason why. There are superior products out there compared to ANYTHING Microsoft has.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
