After release of EF Core 2.2 it is now possible to have both single and collection values of owned types.
In contrast to classical navigational properties owned types are always included in the entity, so owned types looks like a natural way of describing the shape of an aggregate.
Are there any DDD related use cases where classical navigation properties are still better?
Update 1
Prior to 2.2 I was able to call modelBuilder.Entity<OwnedType> and configure alternative key.
Now with 2.2 I started getting errors during migration: primary key is not defined for the entity. However, ReferenceOwnershipBuilder class which is passed as a parameter to buildAction lambda in method OwnsOne does not contain HasAlternateKey. This is currently a known limitation.
Update 2
Currently owned types do not support inheritance. This may be critical for some use cases.
Related
I want to use the EF Core HasData method to seed a database with reference data. Two of the models I want to seed follow the Table per Hierarchy (TPH) pattern in the sense that there is a none abstract base type and another none abstract derived type. These models in the database exist in a table named after the base type with a discriminator column. I would like to add data seeding for this table. However I’m struggling to find any guidelines of how to do so in the EF Core 6 documentation.
I have a few related questions:
Do I seed all the data using the HasData method on an EntityTypeBuilder<BaseType> or do I need to split the seeding into one HasData on that class and another on EntityTypeBuilder<DerivedType>?
I understand using TPH will add a shadow discriminator property and that, potentially, I’ll have to add that in the data seeding. Does that mean I have to use anonymous types to specify that property (doesn’t seem very elegant) and if so, can I get the autogenerated discriminator name using a method (typing it manually sounds like a risk as what if EF Core changes the discriminator name convention?)?
Should I be avoiding using TPH on reference tables altogether? Is there something else I should do instead?
After going through my options with trial and error, I have come to the following solution. It may not be perfect, but it deals with all of my concerns.
Do I seed all the data using the HasData method on an EntityTypeBuilder<BaseType> or do I need to split the seeding into one HasData on that class and another on EntityTypeBuilder<DerivedType>?
You have to do it on both classes, attempting otherwise throws on creating the migration:
The seed entity for entity type 'BaseType' cannot be added because the value provided is of a derived type 'DerivedType'. Add the derived seed entities to the corresponding entity type.
I understand using TPH will add a shadow discriminator property and that, potentially, I’ll have to add that in the data seeding. Does that mean I have to use anonymous types to specify that property (doesn’t seem very elegant) and if so, can I get the autogenerated discriminator name using a method (typing it manually sounds like a risk as what if EF Core changes the discriminator name convention?)?
I have added a property to the BaseType class and defined it as the discriminator, so now I can specify the discriminator values directly without using anonymous type and I am in control of the discriminator values. Gert Arnold points out in this other answer why this might not be appropriate. However I have used the following method described in this EF Core Github issue to hopefully mitigate the concerns he raised.
Should I be avoiding using TPH on reference tables altogether? Is there something else I should do instead?
This is still unanswered. But I am feeling a lot more confident it is a good approach now.
I'm creating my db using code-first and entity framework. I'm defining all my models which works great, but now I have a Page class which can contain Blocks.
These Blocks have a base class with ID, BlockType, Position, Name etcetera but there are different types of blocks with different properties which are classes that inherit from this base class. I'm wondering how I can setup my models so the page can have a collection of 'blocks' without storing the custom properties in a comma seperated list or something like that.
Is it possible? And what is the 'good' way to model this..
Thanks in advance!
Entity Framework supports inheritance. There are various strategies to map your object model - base and derived classes - to a database schema. The most important are:
Table per hierarchy (TPH): Base class and all derived classes will be mapped to a single table in the database. Any custom properties of derived classes will appear as separate columns in the table and the table contains a discriminator column to distinguish between the types. EF manages to load the columns needed to materialize a specific type.
Table per type (TPT): The base class has its own table which only contains the base class properties. Every derived entity gets another table that has the additional properties of this type. EF manages to load the properties from the different tables (creating appropriate joins) that contain all properties to materialize a specific type.
TPT is - in my opinion - the cleaner approach to implement inheritance, but it currently (EF <= 4.3) has performance problems compared to TPH due to suboptimal SQL generated by EF. The problem will be solved in EF 5.0. But TPH will still remain the more performant way of mapping because it doesn't need to join multiple tables.
Benefits and drawbacks of the strategies are discussed in detail in the linked blog posts. In the blog you can also find the third (less often used) option - Table per concrete type (TPC).
So I heard L2S is going the way of the dodo bird. I am also finding out that if I use L2S, I will have to write multiple versions of the same code to target different schemas even if they vary slightly. I originally chose L2S because it was reliable and easy to learn, while EF 3 wasn't ready for public consumption at the time.
After reading lots of praises for EF 4.1, I thought I would do a feasibility test. I discovered that EF 4.1 is a beast to get your head around. It is mindnumblingly complex with hundreds of ways of doing the same thing. It seems to work fine if you're planning on using simple table-to-object mapped entities, but complex POCO object mapping has been a real PITA. There are no good tutorials and the few that exist are very rudimentary.
There are tons of blogs about learning the fundamentals about EF 4.1, but I have a feeling that they deliberately avoid advanced topics. Are there any good tutorials on more complex mapping scenarios? For instance, taking an existing POCO object and mapping it across several tables, or persisting a POCO object that is composed of other POCO objects? I keep hearing this is possible, but haven't found any examples.
Disclaimer: IMO EF 4.1 is best known for its Code-First approach. Most of the following links point to articles about doing stuff in code-first style. I'm not very familiar with DB-First or Model-First approaches.
I have learned many things from Mr. Manavi's blog. Especially, the Inheritance with code-first series was full of new stuff for me. This MSDN link has some valuable links/infos about different mapping scenarios too. Also, I have learned manu stuff by following or answering questions with entity-framework tags here on SO.
Whenever I want to try some new complex object mapping, I do my best (based on my knowledge about EF) to create the correct mappings; However sometimes, you face a dead end. That's why god created StackOverflow. :)
What do you mean by EFv4.1? Do you mean overhyped code-first / fluent-API? In such case live with a fact that it is mostly for simple mapping scenarios. It offers more then L2S but still very little in terms of advanced mappings.
The basic mapping available in EF follows basic rule: one table = one entity. Entity can be single class or composition of the main class representing the entity itself and helper classes for set of mapped fields (complex types).
The most advanced features you will get with EF fluent-API or designer are:
TPH inheritance - multiple tables in inheritance hierarchy mapped to the same table. Types are differed by special column called discriminator. Shared fields must be in parent class.
TPT inheritance - each type mapped to the separate table = basic type has one table and each derived type has one table as well. Shared fields must be defined in base type and thus in base table. Relation between base and derived table is one-to-one. Derived entities span multiple tables.
TPC inheritance - each class has separate table = shared fields must be defined in base type but each derived type has them in its own table.
Entity splitting - entity is split into two or more tables which are related by one-to-one relation. All parts of entity must exist.
Table splitting - table is split into two or more entities related with one-to-one relation.
Designer also offers
Conditional mapping - this is not real mapping. It is only hardcoded filter on mapping level where you select one or more fields to restrict records which are allowed for loading.
When using basic or more advanced features table can participate only in one mapping.
All these mapping techniques follow very strict rules. Your classes and tables must follow these rules to make them work. That means you cannot take arbitrary POCO and map it to multiple tables without satisfying those rules.
These rules can be avoided only when using EDMX and advanced approach with advanced skills = no fluent API and no designer but manual modifications of XML defining EDMX. Once you go this way you can use
Defining query - custom SQL query used to specify loading of new "entity". This is also approach natively used by EDMX and designer when mapping database view
Query view - custom ESQL query used to specify new "entity" from already mapped entities. It is more usable for predefined projections because in contrast to defining query it has some limitations (for example aggregations are not allowed).
Both these features allow you defining classes combined from multiple tables. The disadvantage of both these mapping techniques is that mapped result is read only. You must use stored procedures for persisting changes when using these techniques.
According to Initial POCO Design 1-Pager
Persistence Ignorance refers to being
able to allow the developer to write
and test domain objects in a way that
is entirely independent of fundamental
requirements and assumptions that may
be made by the infrastructure service
(in this case, the Entity Framework).
Such requirements / assumptions may
often include:
The need to implement a specific interface (for e.g., IPOCO)
Inheritance from a base class
Providing specific constructors
Object Instantiation/Construction requirements – use a specific factory
for instance**
The need for metadata or mapping class or property Attributes
The need to use specific relationship mechanisms
This amounts to being able to use
Plain Old CLR Objects (POCO) so that a
developer can author their domain
objects free of all assumptions and
requirements imposed by the framework.
Using this approach, once the domain
objects are ready to their
satisfaction, the developer can use
these classes with the Entity
Framework in order for relational
database access and persistence.
As of right now (CTP5), is there any way at all to reconstitute a poco using a parametrized constructor? If not, it's hard to see how the Entity Framework can be said to offer persistence ignorance.
You can have as many parameterized constructors as you want, so long as the framework has access to a parameter-less one, which is available by default if you you have no constructors, or if you provide one in addition to the parameterized ones you create.
For part of the project I'm currently working on, I have a set of four tables for syndicatable actions. One table is the abstract base for the other three, and each table is represented in my EF model like so:
EF Model -- Actions http://chris.charabaruk.com/system/files/images/EF+Model+Actions.png
There are two problems that I'm currently facing with this, however. The first problem is that Actor (a reference to a User) and Subject (a reference to an entity of the class associated with each type of action) are null in my subclasses, despite the associated database columns holding valid keys to rows in their associated tables. While I can get the keys via ActorReference and SubjectReference this of course requires setting up a new EF context and querying it for the referenced objects (as FooReference.Value is also null).
The second problem is that the reciprocal end of the relationship between the concrete action classes and their related entity classes always turn up nothing. For example, Task.RelatedActions, which should give me all TaskAction objects where Subject refers to the particular task object on which RelatedActions is called, is entirely devoid of objects. Again, valid rows exist in the database, Entity Framework just isn't putting them in objects and handing them to me.
Anyone know what it is I'm doing wrong, and what I should do to make it work?
Update: Seems that none of the relationship properties are working in my entity model any more, at all. WTF...
I think the issue you are experiencing here is that by default the EF does not automatically load related entities. If you load an entity, the collection or reference to related entities will be empty unless you do one of the following things:
1) Use eager loading in order to retrieve your main entity and your related entity in a single query. To do this, modify your query by adding a call to the Include method. In your sample above, you might use the following query:
from a in context.Actions.Include("Actor") select a
This would retrieve each of the actions with the related Actor method.
2) Use explicit lazy loading to retrieve the related entity when you need it:
action1.ActorReference.Load()
In the version of the EF which will ship with .Net 4.0, you will also have the following additional option:
3) Turn on implicit lazy loading so that related entities will automatically be retrieved when you reference the navigation property.
Danny