Comment by smt88 | Hacker News Reader

Comment by smt88 | Hacker News Reader

Parent Full thread

I'm using C#/.NET 4.5.2 for the first time at a small startup. The original architect came from a bank. He's a fantastic programmer and he organized the code in a logical, easy-to-maintain way.

Still, we spend about 30% of our working time (30%!) fighting the tooling. Visual Studio 2015 is a buggy mess, and 2017 wouldn't even build our projects. Everything happens at a snail's pace and is incredibly complicated.

The error messages are opaque to the point of making me laugh out loud at times, and doing even tiny things (like changing the status code of the response in the API) is complicated and hidden away under many layers of magic.

Don't even get me started on Entity Framework. What a fucking disaster. When it works, it's amazing! When it doesn't work (or when you need to do something simple, like update a row) it becomes a black swamp of meaningless error messages and trial-and-error frustration. Our most experienced engineers have been working with .NET and EF for many years and still couldn't figure out how to do an update (in one particular case). The solution? Write a raw SQL query with a "TODO: use EF" comment added. Time lost? TEN hours. I'm not even kidding.

Maybe people who like .NET have never had a better experience, but I can assure you that even with great engineers at a small shop, it is not even close to the best experience. Comparisons to Java are accurate.

For anyone that might not be familiar, Entity Framework is an ORM (object-relational mapper). The "blessed" way of doing an update is to retrieve an object from your context, change its properties, and call SaveChanges on the context. Yes, this can be terribly inefficient, particularly if you're trying to update many rows at once. But it works okay for single-row updates in a CRUD app at the expense of having to run the SELECT first plus all the reflection and change tracking.

If you want to do fast, single-call updates without first doing a SELECT, or updates on just a few of the row's columns, since that can't easily be done with tracked objects, you're swimming upstream against what ORMs are designed to do and so your best option is to get out of ORM land and do a SQL query. Using context.Database.SqlQuery() or another library for these purposes like Dapper to parameterize your queries via reflection could help here.

> Dapper

This is all I use now, it's fast and lightweight, works with MSSQL and MySQL and I'm not averse to getting down and dirty with dynamic objects instead of having to define POCO's upfront. It's a hugely productive tool for me. I also don't mind writing raw SQL statements and I don't need to worry about having to abstract away the DB because these apps are targeted for specific DB products.

Before Dapper when I went in search of ORM's for .NET I tried NHibernate, but too much config ceremony. Then I had a short dalliance with LINQ to SQL, it wasn't terrible, but it was a bit of a pain to work with legacy DB stuff, same with backing in new table columns/changes (sure I could edit the .dbml files directly then regen the .designer.cs, but meh).

I had a look at EF 4.x but at the time its support for enums was non-existent (it took until 5.0's release in 2012) and that was a deal breaker. It was also just too much of a monster and got in the way, and I found myself more often tha not executing SQL directly via the data context.

So yes, Dapper, thank you Mark Gravell, Sam Saffron and Nick Craver for with wonderful tool.

IF you have the primary key of the entity that you want to update, EF allow you to attach it to the context without querying the database. After attaching it to the context, you can set the new values, mark them as modified and (finally!) call SaveChanges.

---

I do agree with you though! Dealing with it's limitations and edge case mean, sooner or later, falling back to SQL.

EF is (imho) very hard to master and very easy to use "badly".

> The "blessed" way of doing an update is to retrieve an object from your context, change its properties, and call SaveChanges on the context.

Yes, we know. As I said, we had multiple people who had been using .NET and EF for years.

> Yes, this can be terribly inefficient

I wasn't talking about efficiency. We're not at a stage where we're optimizing our queries. We just want code that works and is inexpensive to maintain.

In this case, we just wanted EF to work at all. We never figured out why it wouldn't work. We got a weird, opaque error message. Our code was laughably simple: create the context, update a row, SaveChanges. That's it.

Just trying to constructively help the community and build the body of knowledge around EF. I'd be interested in seeing example code to reproduce your issue, and I'd be happy to look into it. If there is a case where EF errors updating records, it would be good to help people know what to avoid or how to work around it, or possibly even submit a fix to the project. I've never seen a scenario that you're describing in my years with EF so it intrigues me. If you can make a gist or something that would be awesome. Or at least the error message as you described. I assume it was something like "An error occurred updating the entities", in which case the error message(s) from InnerException would be needed to diagnose.

My most likely paths of diagnosing that issue would be to make sure the object is properly tracked in the context, ensure there aren't data type issues (i.e. having a System.DateTime value be default(DateTime) for a SQL datetime column that is out of range), make sure it isn't trying to update a computed/identity column, look for special SQL data types (geospatial, XML), if validation is turned on at the context level ensure the properties validate against the DataAnnotations, etc.

I wish I could circle this response and write EVERYONE READ THIS. Agree with you 100%

I work as a consultant at a large fortune 500 company and have been writing .net for years. My colleagues are top notch senior .net and Java developers, not because they came from a bank, because they all have been writing .net since it came out, ARE GOOD AT IT, and regularly practice other languages. This post erks me.

I will admit, VS 2015 has some issues, its less reliable than its predecessor, (the new nuget package manager is horrific) however its still an amazing IDE. I will also admit EF can have a bunch of little frustrating facets if you don't know all the intricacies. Read an EF book. What I will disagree with you on is that senior .net developers have never seen the sun and will never know that their lives suck because they haven't experienced anything else.

We have an enormous code base in .net with priority in millions of dollars, we use EF at the core and we do not run into issues like you describe because we know how its used. This tells me your developers, while maybe very good developers in their own right, are not as experienced in .net like you say.

You said you love EF when it works, well learn why it isn't working when its not working, and you will fall in love I promise.

EF is really really bad. I will never touch it again. I really don't have any reason not to use something more sane like Dapper. Spend hours on getting complex queries to work just to discover they're horribly slow. I'm not a huge sproc advocate but yes sprocs over EF when doing complex queries every time if I need to choose.

I have used other stacks that are less magical and just as efficient. Abstractions don't have to be complicated or opaque.

You say to learn the stack better? Fine. That huge learning curve makes turnover expensive and drastically limits the pool of devs I can hire.

With, say, Python, I can hire any smart dev and she can learn the language and ecosystem enough in a few weeks to be productive.

What sort of problems have you had with Visual Studio 2015? I've been using it for a while, and have found it (mostly) pretty nice to work with.

I can't say I've worked with Entity Framework before, but I've always believed it to be an abomination. Looks like I'll continue to avoid it.

I wouldn't call it an abomination per se, but it is a very heavy ORM in my opinion. It works well for CRUD, but can be a dog in performance for very complex queries. (These type of queries can be offloaded into stored procs, of course... but inexperienced developers might "forge ahead" and create low-performance code in EF, unfortunately...)

From my perspective, my biggest problem with EF is that Microsoft seemed to half-abandon any concept of "light weight data access layer" (like the previous Linq to SQL), and pushed Entity Framework as The One True Way to call the data layer. EF is definitely suitable for Microsoft's "core audience" of large, enterprise-y CRUD apps, but IMHO it's rather heavy for a simple web page with a few data calls. Fortunately there's things like Dapper that are great for small quick apps.

EF Core is much lighter-weight and tries to be a best of both worlds, pushing some of the heavier stuff into extensions/plugins rather than out of the box. This is why some of the fans of the heavy old EF dislike EF Core, but I'm happy EF Core takes an overall lighter-weight approach.

There's no reason you can't keep using Linq-to-SQL. It's not the new hotness, but it still works just fine. If you're doing SQL Server, I wouldn't see any reason not to use it.

I may have Stockholm syndrome, though.

Builds randomly hang, dependencies disappear when changing branches, weird errors that tell me to reinstall the IDE... everyone on my team has them.

We now have a VM image that we launch in the cloud whenever we need to reset VS. It's ridiculous.

Fascinating. Are y'all using ReSharper by any chance? Every time I've seen those sorts of problems in VS and helped colleagues diagnose them it has been ReSharper causing them directly or indirectly.

I'm not a fan of ReSharper, never install it, and it fascinates me how often VS gets blamed for ReSharper's bad behavior.

Not using ReSharper anymore. I absolutely loved it when I used it though. I'm not sure if I caused any problems or not, but I'm not taking a chance anymore.

I haven't touched C# or .NET in ages, but Visual Studio has always been awful. There was a free IDE called SharpDevelop that was miles better. I don't know if it's kept up, and I can't exactly recommend it after not working with C# for so long. Just agreeing with the Visual Studio pain.

Personally, I'm very happy with VS and feel the performance focuses in the last three major versions continues to pay off.

SharpDevelop still exists, though I'm not sure I'd recommend it as it seemed to get stuck in a time warp somewhere around 2012.

MonoDevelop forked from SharpDevelop. Xamarin Studio forked from MonoDevelop. In an interesting twist of fate, Xamarin Studio is now Visual Studio for Mac and looks to be integrating a lot more of Visual Studio in future releases.

This makes me feel a bit better about sticking with ol' ADO.Net.

Depending on your use case, that can have disadvantages too. For example, I imagine it would be quite difficult to refactor your code around any database schema changes if you're writing raw SQL queries in ADO. Many modern ORMs, including Entity Framework, have a "code-first" approach, allowing you to modify your mapped objects in code and then programatically perform the related schema changes in the database. In a compiled language like C#, this makes refactoring fairly painless. Also, ORMs do reduce a lot of boilerplate code needed to perform CRUD operations, reducing the potential of introducing new errors into your data access layer.

While I understand that ORMs are not for everyone, and certainly have their limitations, I think that in this day in age, they're at least worth investigating. Even in the .NET space, there are other ORM options to choose from aside from Entity Framework.

I'll have to admit the lack of ability to do quick refactoring has bitten me on more than one occasion.. :/

Depending on which version of EF you are using, it is just a wrapper around ADO.Net

Reply on news.ycombinator.com