|
EF entities (classes) can have interfaces; used as a base class; and can be composed of partial classes.
The EF "model" understands tables, entities, and related functions; not specific language features.
The (basic) "table" is in fact a "base" class candidate; while a view is a single or multi-table "interface" of selected columns.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Clearly EF is not everyone's cup of tea, but I think things could be worse e.g. when you would have to use NHibernate 
Here is an overview of some alternative ORMS[^]
|
|
|
|
|
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 
|
|
|
|
|
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.
|
|
|
|
|
I'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.).
|
|
|
|
|
Using base classes to define common properties for multiple entities just works, in both EF Core and EF6. For example, I often use a TrackedEntity class:
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. 
|
|
|
|
|
Good 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
|
|
|
|
|
Are you using Database first or Code first?
|
|
|
|
|
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.
|
|
|
|
|
I 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
|
|
|
|
|
Quote: 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
|
|
|
|
|
|
So I figured out awhile ago how to prepare a massive amount of information about a pixel format based on a few inputs about it, where the compiler computes the rest at compile time. It's all powered by C++ templates. It implements code, to for example, shift a 6 bit value out of the middle of a 16 bit big endian word, give it you you, and then allow you to change it.
You define the bit depth of every channel, and what type of channel it is, and it does the rest:
using rgb565be = pixel<
color_model::rgb,
endian_mode::big_endian,
channel_traits<channel_name::R,5>, channel_traits<channel_name::G,6>, channel_traits<channel_name::B,5> >;
and then you can get the channel info from a pixel type like this:
using ch = typename PixelType::channel_type_by_index<Index>;
printf("channel %s\r\n",ch::name_());
printf("\tindex: %d\r\n",(int)ch::index_);
printf("\tbit-depth: %d\r\n",(int)ch::bit_depth_);
printf("\tmin: %llu, max: %llu\r\n",(unsigned long long)ch::min,(unsigned long long)ch::max);
printf("\tscale: %llu\r\n",(unsigned long long)ch::scale);
printf("\r\n");
It computes all those values above (the trailing underscores are to avoid conflicts with virtual instance methods of the same name that allow you to get the information at runtime rather than compile time like above)
Pretty slick, if I do say so myself, but...
I want to be able to automatically generate code to convert pixel formats of the same color model to each other, so you can for example, from 24-bit RGB to 16-bit BGR format without missing a beat or writing code to do it yourself.
So I needed a template to fetch a channel by name at compile time.
I can get it, but I can't populate the index of the channel with a meaningful value if I don't retrieve it by index. Nor can I count the bits to the left of it which means that nifty shifting code I generate is incorrect if I fetch the channel type by name.
I'm stumped by the seemingly simple task of convincing the C++ compiler to give me the index of type (within a template argument parameter pack) that has a particular string associated with it.
I've been working on this all day.
I love C++.
I hate C++.
Real programmers use butterflies
|
|
|
|
|
Any progress? I'm no template wizard so can't help.
You're clever regardless of how this turns out.
|
|
|
|
|
Update: I fixed it. Eureka!
template<size_t Count,typename Name, typename ...ChannelTraits>
struct channel_index_by_name_impl;
template<size_t Count,typename Name>
struct channel_index_by_name_impl<Count,Name> {
static constexpr size_t value=-1;
};
template<size_t Count,typename Name, typename ChannelTrait, typename ...ChannelTraits>
struct channel_index_by_name_impl<Count,Name, ChannelTrait, ChannelTraits...> {
static constexpr size_t value = is_same<Name, typename ChannelTrait::name_type>::value ? Count : channel_index_by_name_impl<Count+1,Name, ChannelTraits...>::value;
};
Above is the magic I needed
I still haven't figured it out. It's not catching my specializations that I set up for some reason.
This is my i don't know which iteration now.
#define GFX_CHANNEL_NAME(x) struct x { static inline constexpr const char* value() { return #x; } };
...
template<bool Value>
struct boolean_type {
constexpr static const bool value = Value;
};
template<typename T, typename U>
struct is_same : boolean_type<false> {};
template<typename T>
struct is_same<T, T> : boolean_type<true> {};
template<typename PixelType,typename Name,size_t Count, bool Match, typename ChannelTrait,typename... ChannelTraits>
struct channel_index_by_name_impl {};
template<typename PixelType,typename Name,size_t Count, typename ChannelTrait,typename... ChannelTraits>
struct channel_index_by_name_impl<PixelType,Name,Count,false,ChannelTrait,ChannelTraits...> {
constexpr static const size_t value = Count;
using next = channel_index_by_name_impl<PixelType,Name,Count+1,is_same<Name,typename PixelType::channel_type_by_index<Count+1>::name_type >::value,ChannelTraits...>;
};
template<typename PixelType,typename Name,size_t Count, typename ChannelTrait,typename... ChannelTraits>
struct channel_index_by_name_impl<PixelType,Name,Count,true,ChannelTrait,ChannelTraits...> {
constexpr static const size_t value = Count;
};
Here the ChannelTraits parameter pack has channel_traits definitions in it, and each of them has a name_type which is a type alias for one of those #defined "strings" above.
The idea is it keeps instantiating the next one in the series until is_same for the next template's name_type is true.
The problem is it always seems to stop at the first one.
Real programmers use butterflies
modified 21-Mar-21 21:08pm.
|
|
|
|
|
Definitely worth a bookmark in case I need a good template example to look at.
|
|
|
|
|
I'm in the middle of working on an article titled Metaprogramming in C++: A Gentle Introduction
It will cover this, and several other techniques.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: I love C++.
I hate C++
Best explanation so far.
Ditto, on Delphi. It is wonderfull, except for those few lines of assembly with the comment "magic".
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I figured out my issue though and unlike with other languages, it feels like I accomplished something significant.
I was just talking to a friend about how C++ development is a field unto itself. Creating a program in C++ is like writing a dissertation. You could spend a lifetime studying C++ and never master it. Just when you think you have, someone figures out a novel way to hack the compiler and opens up an entire new subfield like happened with metaprogramming.
I can't say the same of any other language I've used, at least not to that degree. It's in a class by itself. The standard C++ compiler is pure magic. Oh, the things it can do. It boggles the mind.
Real programmers use butterflies
|
|
|
|
|
Sophia, Rose, Blanche and Dorothy.
Some of you will understand.
Real programmers use butterflies
|
|
|
|
|
SRBD ?
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
|
No, it's not an acronym, it's an old American pop culture reference. You'd have had to watch American television in the 1980s and 1990s.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: You'd have had to watch American television in the 1980s and 1990s.
I didn't have american TV but I did know them.
My favourite was the granny... 
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
that was Sophia. We named the smarter hen after her.
Real programmers use butterflies
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
