Settings.StoredProcedureReturnModelRename

Renames the class the generator invents to hold a stored procedure's result set.

Type	Func<string, StoredProcedure, string> - parameters (defaultName, sp), returns the new name
Default	Returns the default, which is the procedure name plus ReturnModel
Applies to	EF 6 and EF Core
Databases	SQL Server and PostgreSQL, which are the two that can discover a result shape. See the gotchas
In Database.tt?	Yes, with a commented-out example

What it does

When a procedure returns rows, the generator has to put them somewhere, so it invents a class. By default it is named after the procedure: GetStudentsByCourse returns List<GetStudentsByCourseReturnModel>.

That is unambiguous and ugly, and it leaks a verb into a type name that is really a noun. This callback lets you name the type after what it is rather than after the procedure that produced it.

Example

Settings.StoredProcedureReturnModelRename = delegate(string name, StoredProcedure sp)
{
    return sp.NameHumanCase == "GetStudentsByCourse" ? "StudentSummary" : name;
};

Before

List<GetStudentsByCourseReturnModel> GetStudentsByCourse(int? courseId);
List<sales_GetOrderTotalsReturnModel> sales_GetOrderTotals(int? year);

After

List<StudentSummary> GetStudentsByCourse(int? courseId);
List<sales_GetOrderTotalsReturnModel> sales_GetOrderTotals(int? year);

sales_GetOrderTotals is untouched because the rule did not match it - returning name is how you say "leave this one alone".

When to use it

Naming the shape, not the query. StudentSummary is a type you can pass around; GetStudentsByCourseReturnModel is a type you apologise for.

Sharing a model between procedures. Two procedures returning the same columns can return the same type:

Settings.StoredProcedureReturnModelRename = (name, sp) =>
    sp.NameHumanCase.EndsWith("Summary") ? "SalesSummary" : name;

Only do this when the shapes really are identical - see the gotchas.

Stripping the suffix wholesale, if you find ReturnModel more noise than signal:

Settings.StoredProcedureReturnModelRename = (name, sp) =>
    name.EndsWith("ReturnModel") ? name.Substring(0, name.Length - "ReturnModel".Length) + "Result" : name;

Gotchas

Two procedures given the same model name must have identical result shapes. The generator emits one class per distinct name; if the column sets differ, whichever is generated first wins and the other procedure's callers get a type missing its columns. Nothing warns you.

Clashing with an entity name is worse than it looks. Return "Student" for a procedure while a Student entity exists and you get two classes called Student in one namespace, which does not compile. If the procedure genuinely returns an existing entity, do not rename the model - use Settings.StoredProcedureReturnTypes to make the procedure return that entity and generate no model at all.

Multiple result sets are named differently. A procedure with two result sets generates one outer model containing ResultSetModel1 and ResultSetModel2 classes. This callback renames the outer class; the inner ones keep their numbered names.

Only fires where a result model exists. MySQL, Oracle and SQLite produce no return models at all - the callers are generated but there is no class to name. On PostgreSQL only set-returning functions get one. See the database pages.

name is the default, already schema-prefixed. For a procedure outside the default schema you receive sales_GetOrderTotalsReturnModel, not GetOrderTotalsReturnModel.

See also

• Settings.StoredProcedureRename - renaming the method, which the model name follows by default
• Settings.StoredProcedureReturnTypes - returning an existing entity instead
• Settings.UsePropertiesForStoredProcResultSets - fields or properties inside the model
• Stored Procedure Return Model Errors - when no model can be discovered
• Settings Callbacks | Settings Reference