Hacker News Reader

Comment by bayesian_horse | Hacker News Reader

I'm a newcomer, having been forced to use .NET for work. I really wanted to keep an open mind. But I really can't recommend .NET for web development to anybody. Performance is really the only benefit, and that only gets relevant if you can circumvent or take all the downsides. I really like F# as a language, but C# doesn't really do it for me.

Everything else I've seen is very far behind Django/Python and probably PHP, Ruby, Go and Java, though I have less familiarity with those. Documentation and ecosystem certainly. EF as an ORM is a disappointment. Writing REST APIs is at least five to ten times as cumbersome and a lot more annoying. And I have to struggle a lot more to find libraries and support.

And it's not just a problem of being anti-Microsoft. Microsoft is running the show and can decide virtually anything (but not everything). You have to be Ok with that, whatever that means for you and your business.

View on HN

> EF as an ORM is a disappointment

How come? It's one of the few things I'm really missing since switching most of my development work away from dotnet. EF Core + LINQ give you type-safe and very compact queries. I don't think there's anything similar for Hibernate, for example: there is JPA Specification API with metamodel generation. The idea is very similar, but with much more boilerplate.

Same experience here. Used EF as code-first and structuring queries with LINQ has been a breeze. Really really enjoyed working with it.

There are three problems than an ORM should solve to some degree:

1. Type safety/refactorability

2. Composability (can I reuse my queries)

3. Expressivity (can I generate the queries I want)

Of these, EF only solves the first, which is far and away the easiest of the three.

Composability in EF is possible via expression tree splicing, however it requires such a degree of discipline and insight that I have never seen anyone do it, or even any discussion around it.

Like almost everything in the .NET ecosystem, EF makes a bunch of promises that are fantastic for hello world, but are disastrous as your project grows.

Do you have any specific examples of an ORM that ticks two (or all or three) of these?

It's a hard problem, NHibernate actually came a little bit closer with it's QueryOver API. The most glaring problem with the LINQ API is there is no way to OR two reusable conditions together because the only tool you have is Where.

To be clear you can get a long way by abusing EF's willingness to try and interpret arbitrarily complex expressions - it just provides zero tooling or guidance on how to build those expressions.

Or projections. It's possible to write a reusable projection for EF like so:

    class MyTableProjection {
      public static Expression<Func<MyTable, MyTableProjection>> Expression =>
        t => new MyTableProjection {
       Id = t.Id,
       Str = t.Str,
       Flag = t.Flag
     };
    
      public int Id { get; init; }
      public string Str { get; init; }
      public bool Flag { get; init; }
    }
    
    dbContext.MyTable
    .Where(...)
    .Select(MyProjection.Expression)
    .ToListAsync()

But I have never seen anyone do this because it breaks the promise that you magically won't have to write any code or abstractions.

Automapper solves this. Composable projections to your DTOs/ endpoint return types. You can do some very powerful things with it. For example, in a past project I encrypted/unencrypted a property containing a secure message by defining a function to do so and setting up Automapper to automatically apply the function when mapping to/from the DTO that is sent/received by the API.

It's pretty easy using LinqKit [1]. Just PredicateBuilder.Or() [2]. If you were to try and implement PredicateBuilder yourself that requires a little more knowledge around expressions, but it's worth learning and opens up a lot more possibilities.

[1] https://github.com/scottksmith95/LINQKit [2] http://www.albahari.com/nutshell/predicatebuilder.aspx

SQLalchemy is exceptionally good at all of these -- and I'm not even a power user so I don't know all the tricks.

Re: Composability

You can generate something like the WHERE clause of a query in a function and return it alone (rather than as a SELECT query) or even combine it with another WHERE.

e.g. In SA the "select" and "where" portions aren't tightly coupled.

Re: Expressivity

Right now you can easily build up ef.core queries by chaining IQueryable.Where, which is nice but you can only do that for selects and something like OR conditions are difficult to implement.

e.g. in SA you can just pass a list of predicates to the or_() function.

e.g. in SA you can build a WHERE clause and then pass the same clause to a select or a bulk operation.

For me, the Django ORM was always good enough, EF isn't. Lately, there is also support for type checking I think, but in general, Django is big on validating input data.

The developers have constrained themselves by refusing anything that falls outside of the scope of a strongly typed unit-of-work implementation.

This means we will probably never get: 1. Ability to pull non entity types out of the database without a whole lot of boilerplate. See the bizarre obstinacy here: https://github.com/dotnet/efcore/issues/10753

2. Any kind of bulk insert/delete/update ability. It's been a "to do" for years now.

3. Much better query composability.

Basically their response is to just use raw SQL for anything that isn't a unit-of-work feature. They're missing a lot of benefits that a ORM could provide when they say that.

The ef.core team feels like a lot of rejects that were stack ranked out to their own team. I know that is mean to say, but they iterate extremely slowly compared to teams like asp.net .core, visual studio code, c# language group, f# language group.

This is really interesting to me. I was also forced to use .NET for work a few months ago, but coming from Python, I found that I tend to like rather than dislike most of the differences between the ecosystems.

The whole ordeal with the enterprise application structure was a hassle for me to begin with, but after some mentoring and guidance from a senior developer, it all made sense in the end, and I started to apply the same kind of structure in my Flask projects.

What is it that you found C# to be lacking in compared to what we're used to in the Python world?

For me Flask is obsolete. If I want a feature-rich web framework I go with Django, if I want (more) performance and simplicity, I go with FastAPI.

Comparing .NET to Flask is much easier on .NET, since it doesn't have all those Batteries included and yet doesn't reap the benefits from an async/type annotation approach like FastAPI.

In general, I miss all the readability, conciseness, documentation, availability of third party packages...

Also Django Rest Framework makes it a lot easier to get up and started.

Frankly, ASP.NET is just too full of magic.

I forget sometimes how bad and confusing it is because I'm still mostly using NancyFx, which has a much simpler and explicit way of defining routes.

Try minimal apis. Is not nancyfx archived?

It is, yes, and because everything Nancy did, ASP.NET Core can now do - it really is a vast improvement over the old ASP.NET.

There is another OSS project, Carter, that builds on the ASP.NET Core goodness, allowing you to define endpoints the same way as you did in Nancy.

Go really? Last I checked its impossible to write an ORM in go, didn't even have a way to do dynamic routing that I had to implement my own router using a trie. Please.

There's this.

https://gorm.io/index.html

In my opinion Go and C# scratch one itch in common: being more productive than C(++) but still very performant.

But Go has a philosophy of minimal baggage, which is quite the opposite of C#. If that means you can't build a decent ORM, maybe you either don't need an ORM or Go isn't the right fit for that project.

What's cumbersome? EF is really great, so i don't know what could be a disappointment.

( I'm using code first fyi)

I find myself writing at least 5-10 times as much code compared to Python/Django. With the Django ORM once you design your models you already have at least 80% of the logic for a CRUD REST API, form validation, CRUD admin interface (if you want that), and you can easily integrate all sorts of third party features for almost no effort. Migrations are a bit saner because of the App separation, data migrations are a possible.

You can achieve nearly the same thing by creating your Entities, generating migration from them with a single command, migrating your db with another one(or from code on startup) and returning them directly from Controller's method using DB Context. It's honestly not that much more work. It's far from a recommended approach though... Granted, Django Admin is pretty nice and although there are few nugets that try to achieve that I never found them as easy as in Django.

At least in the codebase I work on, I need to create an IRequest/IRequestHandler/Validator class triplet for every single endpoint, each in its own files, including all the lines with single braces and using statements for all the magic extension methods and dependency injection constructors. And often I need to add new ViewModels because the mapping doesn't work correctly.

DRF is much more convenient.

Well this is because you decided yourself to go that route. Amount of work would be the same in Django if you decided on this particular architecture there. It doesn't change the fact that if you want to do a simple CRUD you can do it equally easy in almost every popular web framework these days, just yolo that shit into your Controller and be done with it. What you're doing is way more maintainable though, especially if you work with an actual team.

That's not EF. That's typical cqrs, lol.

Here's a scaffolder as an example if you want to automate things like that: https://github.com/ArmandJ77/CQRSAndMediator-Scaffolding

I don't think you know it very well.

You need to add the correct attributes to your class for form validation ( eg. Required / StringLength )

Then scaffold a MVC controller or an api controller ( It will add the class to your DbContext)

Then add-migration / update-database for your migration.

And it's done

Which leads us to the topic of documentation and on-boarding. And it's still a ton of more code to write, read and maintain.

? No it's not.

Autogenerated migration files that you don't need to touch and 1 class to describe the model + 1 auto inserted line in the DbContext

You can't compare Django to EF Core. Django is more like Visual Studio Lightswitch, which has been killed off.

Reply on news.ycombinator.com