4 ms·

I had to debug some of my own 15 year old C# the other day, quite a reminder of how far .NET has come. Back then I rolled my own ORM and it was fun but not a p

I had to debug some of my own 15 year old C# the other day, quite a reminder of how far .NET has come. Back then I rolled my own ORM and it was fun but not a patch on EFCore. One dark place some .NET devs got caught in the early days was some of the 3rd party ORMs. Nightmare of weird code, proprietary mapping tools and headaches. I am still not sold on linq2sql either. Debugging that is never fun.

hughrr 5y ago
Yeah those ORMs were horrible. We used NHibernate what with being sold down the river by Udi Dahan on domain modelling etc. That was a huge mistake too. Dapper is the only ORM that hasn't screwed us in some way.
jermaustin1 5y ago
Early on I liked Linq2SQL, and I think I still do, but it might be just looking back with rose colored glasses. When I thought I needed better control and performance I wrote my first ORM. Which wasn't really all that ORM-y. It would use reflection to map to an object, but queries definitely weren't linq-able or using IQueryable and walking the predicates to dynamically generate queries. It was more like dataBase.TableName.First("id=@id", new {id = 1}); Which would generate "select * from TableName where id=@id" nothing earth shattering. Joins were done through dataBase.Join(new [] {"table1", "table2" }, new [] {"on table1.id=table2.table1_id"}, "table1.id=@id", new {id=1}); It was ugly and I eventually just replaced it with straight ADO.net. I tried various other ORMs over the years, I eventually just settled on EF since it was not bad, and generates almost sane SQL most of the time.
- thrower123 5y ago
  I still like Linq2Sql better than EF. It always made more sense to me to have a sanely-designed database first and then generate the mapping code from it, rather than the code-first style that seems to be popular with EF. You can do the database-first mode with entity framework, but it is less the happy path that the tooling and documentation tries to nudge you into.
  - Weebs 5y ago
    I've always been frustrated that active record ORMs have completely overtaken tools like Linq2Sql. I don't deny the value of the active record pattern where it works, but in almost every case I've used SQL over the past 5 years, I don't want a complex abstraction layer. I just want something to make it easy and safe to talk to the database for the 90% of straight forward queries we write. With something like that, I feel as though I'd rather write my own active record system than use the configuration based systems we see with EF
torginus 5y ago
I'm kind of sentimental for EF, as I think it can be a handy tool, but in my experience, ORMs of any kind are not suited to serious work, they usually assume that they own the database creation, which is fine when you are building a webshop, but obviously not, when you are interacting with a large existing database. ORM-lites, such as Dapper, which only bind query results to objects, are an obvious exception thoug.
- dpark 5y ago
  It’s my experience that ORM “frameworks” are a net negative for anything that needs scale or performance. They’re optimized for demos and quick setup but fall apart as soon as the system needs to scale. Straight deserialization is generally a win but the “magic” never is and fighting with it when it doesn’t work is way more pain that writing some SQL. Every time I’ve seen a project use an ORM past the proof of concept phase, it ends up with some garbage layer to bypass or “trick” the ORM into doing something acceptable. (e.g. Complex materialized views presented as tables to the ORM so the ORM can just do straight selects without joins).
  - Akronymus 5y ago
    Speaking of databases: In my experience, denormalizing usually doesn't help either with performance. Hell, often normalizing it more leads to it actually being faster. (Assuming appropriate indices)
    - dpark 5y ago
      Depends on the query patterns, but certainly denormalization is not an automatic win.
throwaway6532 5y ago
>One dark place some .NET devs got caught in the early days was some of the 3rd party ORMs. Nightmare of weird code, proprietary mapping tools and headaches. I'm looking at you LLBLGen
- smackeyacky 5y ago
  Also EntitySpaces. Not sure what they were thinking. Anything that used EntitySpaces needed a complete re-write as it spawned a living hell of class definitions and mappings that locked you into a particular style of programming that was hideous.

hughrr 5y ago

Yeah those ORMs were horrible. We used NHibernate what with being sold down the river by Udi Dahan on domain modelling etc. That was a huge mistake too. Dapper is the only ORM that hasn't screwed us in some way.

jermaustin1 5y ago

Early on I liked Linq2SQL, and I think I still do, but it might be just looking back with rose colored glasses. When I thought I needed better control and performance I wrote my first ORM. Which wasn't really all that ORM-y. It would use reflection to map to an object, but queries definitely weren't linq-able or using IQueryable and walking the predicates to dynamically generate queries. It was more like dataBase.TableName.First("id=@id", new {id = 1}); Which would generate "select * from TableName where id=@id" nothing earth shattering. Joins were done through dataBase.Join(new [] {"table1", "table2" }, new [] {"on table1.id=table2.table1_id"}, "table1.id=@id", new {id=1}); It was ugly and I eventually just replaced it with straight ADO.net. I tried various other ORMs over the years, I eventually just settled on EF since it was not bad, and generates almost sane SQL most of the time.

thrower123 5y ago
I still like Linq2Sql better than EF. It always made more sense to me to have a sanely-designed database first and then generate the mapping code from it, rather than the code-first style that seems to be popular with EF. You can do the database-first mode with entity framework, but it is less the happy path that the tooling and documentation tries to nudge you into.
- Weebs 5y ago
  I've always been frustrated that active record ORMs have completely overtaken tools like Linq2Sql. I don't deny the value of the active record pattern where it works, but in almost every case I've used SQL over the past 5 years, I don't want a complex abstraction layer. I just want something to make it easy and safe to talk to the database for the 90% of straight forward queries we write. With something like that, I feel as though I'd rather write my own active record system than use the configuration based systems we see with EF

torginus 5y ago

I'm kind of sentimental for EF, as I think it can be a handy tool, but in my experience, ORMs of any kind are not suited to serious work, they usually assume that they own the database creation, which is fine when you are building a webshop, but obviously not, when you are interacting with a large existing database. ORM-lites, such as Dapper, which only bind query results to objects, are an obvious exception thoug.

dpark 5y ago
It’s my experience that ORM “frameworks” are a net negative for anything that needs scale or performance. They’re optimized for demos and quick setup but fall apart as soon as the system needs to scale. Straight deserialization is generally a win but the “magic” never is and fighting with it when it doesn’t work is way more pain that writing some SQL. Every time I’ve seen a project use an ORM past the proof of concept phase, it ends up with some garbage layer to bypass or “trick” the ORM into doing something acceptable. (e.g. Complex materialized views presented as tables to the ORM so the ORM can just do straight selects without joins).
- Akronymus 5y ago
  Speaking of databases: In my experience, denormalizing usually doesn't help either with performance. Hell, often normalizing it more leads to it actually being faster. (Assuming appropriate indices)
  - dpark 5y ago
    Depends on the query patterns, but certainly denormalization is not an automatic win.

throwaway6532 5y ago

>One dark place some .NET devs got caught in the early days was some of the 3rd party ORMs. Nightmare of weird code, proprietary mapping tools and headaches. I'm looking at you LLBLGen

smackeyacky 5y ago
Also EntitySpaces. Not sure what they were thinking. Anything that used EntitySpaces needed a complete re-write as it spawned a living hell of class definitions and mappings that locked you into a particular style of programming that was hideous.