0
public interface IRecordInformation
    {
         DateTime CreatedOn { get; set; }
         DateTime ModifiedOn { get; set; }

    }
public class CareerApplication : IRecordInformation
    {
        public int CareerApplicationId { get; set; }
        public string Name { get; set; }
        public string FileName { get; set; }
        public string Email { get; set; }
        public DateTime IRecordInformation.CreatedOn { get; set; }
        public  DateTime IRecordInformation.ModifiedOn { get; set; }
    }

Why i am doing this ? Because if i change the interface and remove a property then there should be compile time error that there is no property declared in interface for which the implementation exist in class . This way i can remove the implementation from class . But if i dont use explicit implementation using interface name in class then if i remove a property from interface then that corresponding property will be treated as the property of class itself.

I have tried doing like

public DateTime CreatedOn { get => ((IRecordInformation)this).CreatedOn; set => ((IRecordInformation)this).CreatedOn = value; }

But there is a stack overflow exception for which i am attaching the image

Error i am facing

  • That's because EF can only handle concrete classes, not interfaces. It doesn't even "see" the properties. – Gert Arnold Apr 25 '20 at 08:08
  • Yes you are right . But if i want to implement multiple inheritance than i will have to use interfaces ,if i want to remove some property from interface then there should compile time error so as to remove that property from the class which inherits that interface . Is it possible ? – Anuj Chauhan Apr 25 '20 at 12:37
  • Then you have to pair them with implicit implementations (that link-through to the explicit ones). A bit of a hassle but not uncommon. – Gert Arnold Apr 25 '20 at 18:46
  • @GertArnold Could you give me an example or may be suggest how to do that ? – Anuj Chauhan Apr 26 '20 at 04:58
  • `public DateTime CreatedOn { get => ((IRecordInformation)this).CreatedOn; set => ((IRecordInformation)this).CreatedOn = value; }` – Gert Arnold Apr 26 '20 at 08:45
  • Or simply don't use explicit interface implementation. And consider using Shadow Properties instead to manage and hide your CreatedOn and ModifiedOn properties. https://learn.microsoft.com/en-us/ef/core/modeling/shadow-properties – David Browne - Microsoft Apr 26 '20 at 15:27
  • Yes, that's an alternative. [Here](https://stackoverflow.com/a/52021425/861716) I proposed a way to apply shadow properties to multiple entities. – Gert Arnold Apr 26 '20 at 19:59
  • @GertArnold I used your code example and the following exception was thrown which i am adding in initial post – Anuj Chauhan Apr 27 '20 at 07:30
  • You *also* need the explicit implementations. Four properties in total. – Gert Arnold Apr 27 '20 at 11:01

1 Answers1

0

It works as suggested by @Gert Arnold

public DateTime CreatedOn { get => ((IRecordInformation)this).CreatedOn; set => ((IRecordInformation)this).CreatedOn = value; }
        public DateTime ModifiedOn
        {
            get
            {
                return ((IRecordInformation)this).ModifiedOn;
            }
            set
            {
                ((IRecordInformation)this).ModifiedOn = value;
            }

        }
        DateTime IRecordInformation.CreatedOn { get; set; }
        DateTime IRecordInformation.ModifiedOn { get; set; }

        public bool IsPublished
        {
            get
            {
                return ((IPublishInformation)this).IsPublished;
            }
            set
            {
                ((IPublishInformation)this).IsPublished = value;
            }

        }
        bool IPublishInformation.IsPublished { get; set; }

On my blog you can find out the complete problem i was facing in my project http://blogs.anujchauhan.com/post/2020/05/01/Implicit-to-Explicit-implementations-of-interface-in-class-for-Entity-Framework-Core-Common-Columns-in-table-like-CreatedOn-UpdatedOn-DeletedOn-IsPublished

  • 2
    That's better. Please refrain from referring to your blog too much, otherwise it may be considered as too self-promoting. – S.S. Anne May 01 '20 at 12:42