Question

I have many Azure classes containing fields for date and modified by tracking. Fields such as:

[DisplayName("Created By")]
public string CreatedBy { get; set; }
[DisplayName("Modified By")]
public string ModifiedBy { get; set; }

I want to avoid repetition so I was considering creating a class to contain these such as this:

public class TableServiceEntityRowInfo : TableServiceEntity  
{
    [DisplayName("Created By")]
    public string CreatedBy { get; set; }
    [DisplayName("Modified By")]
    public string ModifiedBy { get; set; }
}

For my data classes then instead of having them inherit from TableServiceEntity I would like to set these up as follows:

public class MyClass : TableServiceEntityRowInfo 
{

}

Is this a valid and sensible way to add additional information to the fields. The reason I am asking here is because I am planning to do this to a lot of classes and I want to ensure I do the right thing.

Answer 1

Yes, this is valid and sensible.

If there are any Azure-specific concerns, I can’t speak to that.

As for the comment about “IS A” vs “HAS A,” I think it can safely be ignored here. Really, it almost comes down to naming style. You’ve named your base class TableServiceEntityRowInfo because it is a TableServiceEntity that has row information. What if you called it instead AuditableTableServiceEntity because it has fields for auditing. Now it is exactly the same, but you can claim that each of the inheriting classes “IS A” AuditableTableServiceEntity.

You may also want to mark your base class as abstract to be clear that it should not be instantiated, only inherited.