Settings.TableSuffix

Settings.TableSuffix

Appends the same suffix to every generated entity class name.

Type	string
Default	null (no suffix)
Applies to	EF 6 and EF Core
Databases	All
In Database.tt?	Yes

What it does

Adds your string to the end of every entity class name. Product becomes ProductDto, Category becomes CategoryDto, and so on. Nothing else changes - the table mapping, the DbSet names and the navigation properties all still work.

It exists for one problem: your generated entities collide with types you already have.

Example

Settings.TableSuffix = null (default)

public interface IMyDbContext : IDisposable
public class MyDbContext : DbContext, IMyDbContext
public class MyDbContextFactory : IDesignTimeDbContextFactory<MyDbContext>
public class Category
public class Product
public class sales_Order
public class CategoryConfiguration : IEntityTypeConfiguration<Category>
public class ProductConfiguration : IEntityTypeConfiguration<Product>
public class sales_OrderConfiguration : IEntityTypeConfiguration<sales_Order>

Settings.TableSuffix = "Dto"

public interface IMyDbContext : IDisposable
public class MyDbContext : DbContext, IMyDbContext
public class MyDbContextFactory : IDesignTimeDbContextFactory<MyDbContext>
public class CategoryDto
public class ProductDto
public class sales_OrderDto
public class CategoryDtoConfiguration : IEntityTypeConfiguration<CategoryDto>
public class ProductDtoConfiguration : IEntityTypeConfiguration<ProductDto>
public class sales_OrderDtoConfiguration : IEntityTypeConfiguration<sales_OrderDto>

The configuration classes follow, so ProductConfiguration becomes ProductDtoConfiguration. The schema prefix stays in front, so sales_Order becomes sales_OrderDto.

When to use it

Two contexts over the same tables. Generating a read model and a write model from one database, in one project, means two classes called Product. A suffix on one of them settles it.

Generated entities alongside hand-written domain types. If Product is already a rich domain object you maintain, generating a second Product into the same namespace is not an option.

Migrating between two versions of a schema, where both need to exist during the transition.

A namespace is usually the better answer to all three - Settings.Namespace with Settings.PocoNamespace costs nothing at the call site once the using is in place, and does not put Dto in front of every reader forever. Reach for the suffix when a namespace is not available: same assembly, same namespace, genuinely two types.

Gotchas

It is not a DTO. Naming a generated entity ProductDto does not make it one - it is still an EF entity that is tracked, lazily loaded and attached to a context. Calling it a DTO and then returning it from an API is how entity graphs end up serialised. If you want DTOs, write them.

The suffix is appended after everything else, including singularisation and the schema prefix. There is no prefix equivalent; use Settings.TableRename if you need one.

It applies to entities only. The DbContext, the interface and the stored procedure return models are unaffected, so MyDbContext stays MyDbContext.

Changing it later is a large diff. Every type name in every generated file moves, and so does every reference in your own code.

See also

• Settings.Namespace and the cross-namespace settings - usually the better answer
• Settings.TableRename - per-table renaming, including prefixes
• Settings.ConfigurationClassName - the suffix on the configuration classes
• Settings Reference