Comment by intrasight
5 hours ago
I use EF now - but only for the string interpolation in Database.SqlQuery and Database.ExecuteSql. We don't use POCOs but instead use XML and JSON with Linq.
5 hours ago
I use EF now - but only for the string interpolation in Database.SqlQuery and Database.ExecuteSql. We don't use POCOs but instead use XML and JSON with Linq.
It's really the navigations that make EF a problem. I've built a typed object graph database on top of Sqlite that works really well specifically because it's in Sqlite, so the overhead of the 1+N query problem with recursively descending navigations isn't a big problem. But it requires lazy loading and that requires all the navigation to happen inside a single service scope and that makes sequencing some things get difficult (can't just pass the results around willy nilly).
The navigation system in EF is where all of the pain points originate. All of my troubles with getting the migration generator to work are because I'm trying to express rather complex relationships. For example, to store a record representing a property on an object, I need to have two foreign keys from the Properties table to the Types table: one for the type of the property and one for the type in which the property lives. Types themselves have many relationships to other types: their base type, interface types they implement, generic type parameters, constraints on generic type parameters (actually, haven't even implemented that one as is too much).
I'm generally happy with the performance and expressivity of the system I've developed so far, but damn, it came with a lot of pain.