I'm stunned at how stupid EntityFramework is
-
And how it just does not work with interfaces or base classes. At least, I can't get it to work, so maybe I'm stupid. Doing some googling, there's things like
HasBaseTypethat have to be manually coded in theOnModelCreatingmethod, or in the query, potentially using.Include, but really. Why can't it just figure out what to do based on the class structure? Maybe it's me. But I can understand why people use Dapper. :sigh:Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsUsing base classes to define common properties for multiple entities just works, in both EF Core and EF6. For example, I often use a
TrackedEntityclass:public abstract class TrackedEntity
{
public DateTimeOffset CreatedDate { get; set; }
public string CreatedBy { get; set; }
public DateTimeOffset? UpdatedDate { get; set; }
public string UpdatedBy { get; set; }
}public class Foo : TrackedEntity
{
public int Id { get; set; }
...
}public class Bar : TrackedEntity
{
public Guid Id { get; set; }
...
}Each table will have the properties from the base class. If you want more complicated things, there's always Table-per-Type or Table-per-Hierarchy options: Inheritance - EF Core | Microsoft Docs[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
And how it just does not work with interfaces or base classes. At least, I can't get it to work, so maybe I'm stupid. Doing some googling, there's things like
HasBaseTypethat have to be manually coded in theOnModelCreatingmethod, or in the query, potentially using.Include, but really. Why can't it just figure out what to do based on the class structure? Maybe it's me. But I can understand why people use Dapper. :sigh:Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsAre you using Database first or Code first?
Wrong is evil and must be defeated. - Jeff Ello
-
And how it just does not work with interfaces or base classes. At least, I can't get it to work, so maybe I'm stupid. Doing some googling, there's things like
HasBaseTypethat have to be manually coded in theOnModelCreatingmethod, or in the query, potentially using.Include, but really. Why can't it just figure out what to do based on the class structure? Maybe it's me. But I can understand why people use Dapper. :sigh:Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsI never use EF -I learnt it and decided my own BL/DataAccess model was better and much more flexible. I have a base BL which has its own connection class and I can get a new project CRUDABLE in a very short time. I understand why people use it but it's not for me.
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
-
And how it just does not work with interfaces or base classes. At least, I can't get it to work, so maybe I'm stupid. Doing some googling, there's things like
HasBaseTypethat have to be manually coded in theOnModelCreatingmethod, or in the query, potentially using.Include, but really. Why can't it just figure out what to do based on the class structure? Maybe it's me. But I can understand why people use Dapper. :sigh:Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsQuote:
But I can understand why people use Dapper
It will still underperform compared to using the drivers directly - which, as we all know, isn't all that hard.
Espen Harlinn Senior Architect - Ulriken Consulting AS The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.Edsger W.Dijkstra
-
Maybe you'll get a mail someday that starts with "I have been maintaining your code for a decade now, and I really HATE you!" :laugh:
Quote:
I have been maintaining your code for a decade now, and I really HATE you!
IMHO: If you work for a decade doing plain CRUD, without automating the process, you should probably look for a different profession …
Espen Harlinn Senior Architect - Ulriken Consulting AS The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.Edsger W.Dijkstra
-
You mean it should create tables based on your inheritance structure? EF can deal with regular inheritance and interfaces just fine, I guess it kind of ignores it. But if you have a class, say Employee, that inherits from Person, a migration won't magically create two tables with Employee having only the Employee specific properties and a reference to Person. I put everything in OnModelCreating (like types, nullable, etc.). Just because you're using an ORM doesn't mean you don't have to think about your DB structure anymore :confused:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Sander Rossel wrote:
You mean it should create tables based on your inheritance structure?
Nah, I don't want EF creating anything. I just thought I'd try using it, but I want control over the inheritance structure and leave it to my responsibility that the fields defined in the base class are implemented in the table that mirrors the derived class. Seem that it doesn't like that.
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
Using base classes to define common properties for multiple entities just works, in both EF Core and EF6. For example, I often use a
TrackedEntityclass:public abstract class TrackedEntity
{
public DateTimeOffset CreatedDate { get; set; }
public string CreatedBy { get; set; }
public DateTimeOffset? UpdatedDate { get; set; }
public string UpdatedBy { get; set; }
}public class Foo : TrackedEntity
{
public int Id { get; set; }
...
}public class Bar : TrackedEntity
{
public Guid Id { get; set; }
...
}Each table will have the properties from the base class. If you want more complicated things, there's always Table-per-Type or Table-per-Hierarchy options: Inheritance - EF Core | Microsoft Docs[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Hmmm, I think when I was testing this, my failure was in declaring the base class as abstract. Like I said, I might be being stupid. :)
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
Are you using Database first or Code first?
Wrong is evil and must be defeated. - Jeff Ello
Database first, but then I learned that .NET Core 3 / EF doesn't support creating the C# model from the DB model unless you use Scaffold-DbContext from the Package Manager console, and it's a bit stunted. It's annoying that the tooling doesn't implement enough flexibility, but that's par for the course.
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
Personally I like to keep it simple and straightforward, i.e. 1 table => 1 class. i.e. no hierarchy, interface, etc... Works for me! ^_^ You could argue I am ignoring many powerful features... and you would be right! But it works out quite well for me anyway! ;P
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I'm trying to implement a certain degree of abstraction, especially for REST calls, where the entities (tables) are passed in as part of the route and I want CRUD methods that are abstracted so I don't have to write unique code for each context entity. My problem is one of laziness - I know how to do this in different ways, thought I'd see how one might do this with EF, but I'm too lazy and impatient to figure out what hoops, canyons and mountains I have to jump through, create a bridge over, or climb with enough oxygen tanks, to get it to work. Maybe I'll google some more. :laugh:
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
And how it just does not work with interfaces or base classes. At least, I can't get it to work, so maybe I'm stupid. Doing some googling, there's things like
HasBaseTypethat have to be manually coded in theOnModelCreatingmethod, or in the query, potentially using.Include, but really. Why can't it just figure out what to do based on the class structure? Maybe it's me. But I can understand why people use Dapper. :sigh:Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsIf you're going to use Dapper have a look at [SqlKata the dotnet SQL query builder](https://sqlkata.com/) as well :)
-
Sander Rossel wrote:
You mean it should create tables based on your inheritance structure?
Nah, I don't want EF creating anything. I just thought I'd try using it, but I want control over the inheritance structure and leave it to my responsibility that the fields defined in the base class are implemented in the table that mirrors the derived class. Seem that it doesn't like that.
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsI've never had an issue with that... However, I use my entities as just that, entities. "Dumb" classes that do nothing except hold some data. Whenever I want to do something, anything, with that data, I create a model class. I've worked with entities before and it always comes back to bite you (lazy loading, then NOT lazy loading, circular references, etc.).
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Hmmm, I think when I was testing this, my failure was in declaring the base class as abstract. Like I said, I might be being stupid. :)
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsGood to know. At first I was worried it might have been a feature lost during the move from EF6 to EFcore. I'd seen the partial class trick used to apply interfaces/base classes once before; naturally it was about a year after I'd worked on a different project where knowing the feature was available would have let me take a copy/paste code reduction from ~90% to ~98% fewer lines for the segment I was completely rewriting.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
I'm trying to implement a certain degree of abstraction, especially for REST calls, where the entities (tables) are passed in as part of the route and I want CRUD methods that are abstracted so I don't have to write unique code for each context entity. My problem is one of laziness - I know how to do this in different ways, thought I'd see how one might do this with EF, but I'm too lazy and impatient to figure out what hoops, canyons and mountains I have to jump through, create a bridge over, or climb with enough oxygen tanks, to get it to work. Maybe I'll google some more. :laugh:
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsI never used oData.. but it looks like LinQ 2 SQL code over WebAPI, could it be something that would be useful to you? And I remembered being excited about it... but then, in some context it's doomed to obsolescence because exposing the DB is often a no-no.. But it's a god send me think for SPA or private phone apps... Anyway, if you are curious, here is a link: [OData documentation - OData | Microsoft Docs](https://docs.microsoft.com/en-us/odata/)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Personally I like to keep it simple and straightforward, i.e. 1 table => 1 class. i.e. no hierarchy, interface, etc... Works for me! ^_^ You could argue I am ignoring many powerful features... and you would be right! But it works out quite well for me anyway! ;P
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
