Settings.IncludeFieldNameConstants

Settings.IncludeFieldNameConstants

Adds a const string next to each property holding its own name, so you can stop writing property names as string literals.

Type	bool
Default	false
Applies to	EF 6 and EF Core
Databases	All
In Database.tt?	Yes

What it does

For each property Foo, generates public const string FooField = "Foo"; immediately after it.

The point is to give you a compile-time-checked way to refer to a property by name. Anywhere you currently write "CategoryName" as a magic string - a sort expression, a grid column definition, a validation message key - you can write Category.CategoryNameField instead, and renaming the column in the database then breaks the build rather than failing silently at run time.

Example

Settings.IncludeFieldNameConstants = false (default)

    // Category
    public class Category
    {
        public int CategoryId { get; set; } // CategoryId (Primary key)
        public string CategoryName { get; set; } // CategoryName (length: 50)

        // Reverse navigation

        /// <summary>
        /// Child Products where [Product].[CategoryId] point to this entity (FK_Product_Category)
        /// </summary>
        public ICollection<Product> Products { get; set; } // Product.FK_Product_Category

        public Category()
        {
            Products = new List<Product>();
        }
    }

Settings.IncludeFieldNameConstants = true

    // Category
    public class Category
    {
        public int CategoryId { get; set; } // CategoryId (Primary key)
        public const string CategoryIdField = "CategoryId";
        public string CategoryName { get; set; } // CategoryName (length: 50)
        public const string CategoryNameField = "CategoryName";

        // Reverse navigation

        /// <summary>
        /// Child Products where [Product].[CategoryId] point to this entity (FK_Product_Category)
        /// </summary>
        public ICollection<Product> Products { get; set; } // Product.FK_Product_Category

        public Category()
        {
            Products = new List<Product>();
        }
    }

The constants hold the C# property name, not the database column name. Where the two differ - because of Settings.UsePascalCase or a rename - it is the C# name you get.

When to use it

Dynamic sorting and filtering. A grid that sorts by a column name passed from the client:

var sortable = new HashSet<string> { Product.ProductNameField, Product.UnitPriceField };
if (!sortable.Contains(request.SortBy))
    return BadRequest();

Anywhere a property name currently appears as a literal - a DataGridColumn binding, an audit log entry, an error message key.

Leave it off otherwise. It doubles the line count of every entity, and modern C# has better answers for most cases: nameof(Product.ProductName) is compile-time checked, needs no generated constant, and works on types you did not generate.

Gotchas

nameof does the same job for free. nameof(Product.ProductName) is checked by the compiler and survives a rename refactor. The constants earn their place only where you need the name as a const - in an attribute argument, a switch case, or a [CallerMemberName] default - because nameof is a constant expression but some older APIs still want a literal field.

The class gets twice as long. On a forty-column table that is eighty lines of noise between you and the properties. This is the main reason to leave it off.

It holds the property name, not the column name. If you need the database name - to build SQL, say - these constants are the wrong tool. The column name is in the comment beside each property, and available in callbacks as column.DbName.

No constants for navigation properties. Only scalar columns get them.

See also

• Settings.UsePascalCase - which decides what the constants contain
• Settings.UpdateColumn - renaming properties, which the constants follow
• Settings Reference