Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create EF-specific mapping attributes ('data annotations') #10864

Closed
ajcvickers opened this issue Feb 3, 2018 · 9 comments
Closed

Create EF-specific mapping attributes ('data annotations') #10864

ajcvickers opened this issue Feb 3, 2018 · 9 comments
Labels
closed-no-further-action The issue is closed and no further action is planned.

Comments

@ajcvickers
Copy link
Member

Using C# attributes to drive EF mapping is very popular. Currently, we use data annotations (System.ComponentModel.DataAnnotations) for this, which has a couple of advantages:

  • The attributes are not coupled to the EF assemblies, so referencing EF from the domain model is not required to use them.
  • Multiple parts of an application can read the same annotations and act accordingly--e.g. Required for validation and Required for making the database relationship required.

However, there are also several disadvantages:

  • Sometimes the meaning that EF takes from the attribute is not exactly the same as the meaning other parts of the application take--for example, Required for validation and Required for making the database relationship required. This then requires use of the fluent API to override the annotation meaning.
  • Getting new attributes or changes to existing attributes into .NET Core and having those changes propagate through to the .NET Framework as well can be a slow process, and there is a high compat bar.
  • There are a lot of places whether the annotation semantics are very database-specific. Putting these semantics in general non-database-specific attributes is a bad fit.

Because of this, we have already created a new attributes package: EFCore.Attributes. This contains new attributes like OwnedAttribute. This package will not have any references to the main EF Core assemblies so it can be included in a domain model with minimal impact--to avoid this entirely, use the fluent API.

This issue is about creating new, EF-specific, attributes even for concepts already covered by the data annotations. This would then allow higher fidelity mapping for EF Core using attributes instead of the fluent API, with all attributes in a single location that can be iterated on and released as EF Core evolves.

Note that this does not mean that we will stop honoring data annotations--that will keep working--but there will be another option with more EF-specific attributes that can be used optionally.

@elnoor
Copy link

elnoor commented Mar 31, 2018

Hi guys, that would be awesome if there was a data annotation for unique constraint.
https://stackoverflow.com/questions/49526370/is-there-a-data-annotation-for-unique-constraint-in-ef-core-code-first

@ajcvickers
Copy link
Member Author

See also suggestion in #13627

@bricelam
Copy link
Contributor

bricelam commented Jan 29, 2019

Related issues: #11003, #10111, #10059 & #4050

@ajcvickers
Copy link
Member Author

@divega to consider as a duplicate.

@smitpatel
Copy link
Contributor

Duplicate of #10111

@smitpatel smitpatel marked this as a duplicate of #10111 Feb 20, 2019
@ajcvickers ajcvickers added the good first issue This issue should be relatively straightforward to fix. label Sep 2, 2019
@ajcvickers
Copy link
Member Author

See also scenarios in #10111

@rogerhendriks
Copy link

Sorry to see this isn't included in the v5 planning. Stays a matter of personal preference but i like the clean approch of annotations.

@roji roji removed this from the Backlog milestone Jun 18, 2020
@roji
Copy link
Member

roji commented Jun 18, 2020

Removing from backlog to consider closing - we're tracking specific needs in specific issues.

@ajcvickers
Copy link
Member Author

During 5.0 we have agreed on the approach decided here and are executing on it. Given that we have decided that this is the way to go we will track attributes individually and no longer need this overall tracking issue.

@ajcvickers ajcvickers added the closed-no-further-action The issue is closed and no further action is planned. label Jun 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-no-further-action The issue is closed and no further action is planned.
Projects
None yet
Development

No branches or pull requests

7 participants