So I'm currently debating the option of either defining concrete classes with properties, or to go with a metadata-type design. For example:
public class Employee
{
public Guid Id { get; set; }
public string Name { get; set; }
public string EmployeeCode { get; set; }
public string SpecialAssignment { get; set; }
public string SomeFutureProperty { get; set; }
}
Versus a key/value pair design which can be dynamic:
public class Employee
{
public Guid Id { get; set; }
public string Name { get; set; }
public virtual ICollection<MetaKeyValue> Properties { get; set; }
}
public class MetaKey
{
public Guid Id { get; set; }
public string EntityType { get; set; } // could be a dictionary or enum
public string Name { get; set; }
public string Description { get; set; }
public string Required { get; set; }
}
public class MetaKeyValue
{
public Guid Id { get; set; }
public Guid EntityId { get; set; }
public Guid MetaKeyId { get; set; }
public string Value { get; set; } // string isn't the preferred object type
}
So, the debate is that I'm not sure which one is more efficient. The target persistence is a SQL database using Entity Framework. The beauty of the metadata design is that without modifying code and planning a deployment, new "properties" could be added to an entity and the values could be added and retrieved. The negative is that it's not what I'm accustomed to as I am an old-school coder who likes concrete classes that are statically defined. Would the dynamic design bite me in the rear later down the line?