Hard-coding constant values in C# classes is a bad practice that we rarely indulge in here at TAMUS ESI. You will not see very many instances of code like:<\/p>\n
if (someObject.StatusCode == "A")<\/p>\n
We prefer something more like:<\/p>\n
if (someObject.StatusCode == SomeProjectConstants.SomeFieldStatus.Active)<\/p>\n
where SomeFieldStatus is a class like this one in HRConnect 2:<\/p>\n
public static class BppLogFieldCodes
{
public const string FIT = "FIT";
public const string ACH = "ACH";
...
} <\/pre>\nNothing fancy about this, but creating classes\/constants like these takes only moments and helps reduce bugs and makes changing\/adding new codes easier in future releases.<\/p>\n
What isn’t so helpful about this class – or any other basic C# class – is that it doesn’t provide any metadata about the code values. For example, it would be very convenient if the "friendly description" for the FIT code were directly associated with the code property in the BppLogFieldCodes class.<\/p>\n
The usual technique for getting code\/description translation data into an ESI web application is to use a "Lookups" class that knows how to connect to a data source, read a database table (or tables), and create a list of key\/value pairs. The Lookups class will also normally provide caching of the resulting queries to improve performance. The Lookup data is then used to populate dropdowns, radio button lists, etc. Again, nothing fancy.<\/p>\n
Such Lookup classes are all well and good, but having cached lookup data does nothing to eliminate the BppLogFieldsCode class and others like it – the constants are still needed for comparisons, etc., as initially demonstrated.<\/p>\n
But what if we could create a class like this one that includes the lookup metadata in the class definition?<\/p>\n
public static class BppLogFieldCodes
{
[Description("Federal Income Tax")]
public const string FIT = "FIT";
[Description("Direct Deposit")]
public const string ACH = "ACH";
...
} <\/pre>\nThanks to the new AttributeInterrogator class in the So.Esi.Core assembly, it is now possible to annotate your class as shown, then write a simple, one-line method to get a list of lookup data for use in your app’s UI. For example: <\/p>\n
public IList<LookupDataDTO> GetBppLogFieldSets()
{
return MapAttributeListToLookupData(
AttributeInterrogator.GetTypeAttributes<DescriptionAttribute>(
typeof(HRConnectWebConstants.BppLogFieldCodes)));
}<\/pre>\nThe GetBppLogFieldSets method can be used in exactly the same way as methods in the "Lookups" data wrapper class are used now, but no database connection\/access is required.<\/p>\n
So how is this accomplished? <\/p>\n
The So.Esi.Core assembly contains a DescriptionAtttribute class that inherits from System.Attribute and accepts a description as a parameter to its constructor. That allows the [Description] attribute to be applied to a class and its properties. <\/p>\n
The Description attribute can also be applied to a C# enum and its fields. To make enums even more descriptive, a CodeDescription attribute was created to handle the "three-way" mapping that often takes place with an enumeration. <\/p>\n
In the three-way enum scenario, the three values in play are:<\/p>\n
\n
- The enum value itself <\/li>\n
- The lookup code <\/li>\n
- The friendly description <\/li>\n<\/ol>\n
For example, consider the following enum modeled on TrainTraq 3:<\/p>\n
[Description("Role")]
public enum CodedRatingEnum
{
[CodeDescription("APP-EMPLOYEE", "Employee")]
Employee = 1,
[CodeDescription("APP-DEPT-ADM", "Department Admin")]
Good = 2,
... <\/pre>\n} <\/p>\n
The AttributeInterrogator class helps make this metadata convenient to consume. It also allows developers to create their own custom metadata attribute classes and apply them in their applications.<\/p>\n
A quick look at the current implementation of the GetPropertyAttributes method, which is used to scan a class for its metadata, demonstrates how it works beneath the covers:<\/p>\n
public static IList<AttributeInformation<T>> GetPropertyAttributes<T>(object source)
where T : System.Attribute
{
IList<AttributeInformation<T>> result = null;
Type sourceType = source.GetType();
MemberInfo[] members = sourceType.GetMembers();
foreach (MemberInfo member in members)
{
if (member.MemberType == MemberTypes.Property)
{
object[] attrs = member.GetCustomAttributes(typeof(T), false);
if (attrs != null && attrs.Length > 0)
{
if (result == null)
result = new List<AttributeInformation<T>>();
object value = sourceType.GetProperty(member.Name).GetValue(source, null);
result.Add(new AttributeInformation<T>
{
Name = member.Name,
Value = value,
Attributes = attrs[0] as T
});
}
}
}
return result;
}<\/pre>\nAttributeInformation is a simple class in So.Esi.Core:<\/p>\n
public class AttributeInformation<T>
where T : class
{
public string Name { get; set; }
public object Value { get; set; }
public T Attributes { get; set; }
}<\/pre>\nIt is notable only for the Attributes property, which is generic. This is what allows application developers to define their own custom attribute classes for use with the AttributeInterrogator.<\/p>\n
The AttributeInterrogator.GetPropertyAttributes method uses reflection to iterate over the specified class’ properties. It then interrogates over each property to see if a custom attribute of the desired type T is defined. If so, the property name, value, and attribute information is captured in the result list and returned. <\/p>\n
Similar approaches are taken for interrogating class types and enums.<\/p>\n","protected":false},"excerpt":{"rendered":"
Hard-coding constant values in C# classes is a bad practice that we rarely indulge in here at TAMUS ESI. You will not see very many instances of code like: if (someObject.StatusCode == "A") We prefer something more like: if (someObject.StatusCode == SomeProjectConstants.SomeFieldStatus.Active) where SomeFieldStatus is a class like … <\/p>\n","protected":false},"author":6,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15],"tags":[],"class_list":["post-783","post","type-post","status-publish","format-standard","hentry","category-development"],"_links":{"self":[{"href":"https:\/\/mooredynasty.net\/index.php\/wp-json\/wp\/v2\/posts\/783","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mooredynasty.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mooredynasty.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mooredynasty.net\/index.php\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/mooredynasty.net\/index.php\/wp-json\/wp\/v2\/comments?post=783"}],"version-history":[{"count":1,"href":"https:\/\/mooredynasty.net\/index.php\/wp-json\/wp\/v2\/posts\/783\/revisions"}],"predecessor-version":[{"id":784,"href":"https:\/\/mooredynasty.net\/index.php\/wp-json\/wp\/v2\/posts\/783\/revisions\/784"}],"wp:attachment":[{"href":"https:\/\/mooredynasty.net\/index.php\/wp-json\/wp\/v2\/media?parent=783"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mooredynasty.net\/index.php\/wp-json\/wp\/v2\/categories?post=783"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mooredynasty.net\/index.php\/wp-json\/wp\/v2\/tags?post=783"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}