3 ms·

Migrations have been painful in EF. No easy way to separate models/migrations for the same db context like with Django apps. Metadata for the models is hard to

Migrations have been painful in EF. No easy way to separate models/migrations for the same db context like with Django apps. Metadata for the models is hard to come by (probably there is a way?). Support for advanced Postgres datatypes slowly becomes ready for primetime, but currently isn't, and it's certainly about ten years behind Django in that regard. In Django, a model alreay contains all the meta data and you need almost no code to generate CRUD views and APIs from it. Can't do that in Dotnet. I think I could make something like that but why bother and take the pain? When dotnet people say "my experience" then they mostly mean no experience beyond dotnet (in my experience). I hope you are basing your comparison on more than a glance or a weekend project trying out Django...

acedTrex 4y ago
> Support for advanced Postgres datatypes slowly becomes ready for primetime, but currently isn't, and it's certainly about ten years behind Django in that regard. What type support is lacking in the ef pg provider? > Metadata for the models is hard to come by (probably there is a way?). I'm not sure what metadata means here exactly, you can configure models with either the fluent api or the attribute api
- bayesian_horse 4y ago
  Json(b) columns, (multidimensional) Arrays. By metadata I indeed mean info on what a field means: Human readable names, descriptions, hints on validation or user input fields. You can argue that's not the ORM's job, but having some of that already in the ORM allows Django to have CRUD apis and views with very little code beyond the models. I think you could make something like DRF or Django admin on top of EF by abusing assembly introspection. But so far nobody dared to do that.