Why use T4 to modify entities in EF?

Question

What is a valid reason for using the 'ADO.NET EntityObject Generator' with EF? In case you don't know, it generates a T4 file that does the building of the entities from the edmx. You can then change the T4 file to change how the entities are generated.

My question is: other than changing the base class in which entities are derived (also implementing interfaces) and changing the accessibility of entities and/or the context objects and naming conventions, what use does this have? Considering the existing features of EF and partial classes.

I've come up with 2

1. Grab the table/column descriptions from the database and populate the summary on the entities and properties
2. Generate light wieght DTO's and do auto mapping.

1 seems like too much work considering it only updates the comments on the models, not the edmx itself (although it could do so)

2 Is this even useful?

Answer 1

We have done a few things with the T4 templates. The first one is to split out the generated code into one class per file, instead of one massive file. This just makes it easier to navigate and browse through the entities.

The second, and more important one, is to automatically generate data annotation validation attributes such as StringLength and Required. This lets us validate our entities with a single function call, and it makes sure that their validation attributes are always in sync with the database (since if we change a column length in the DB, for example, the generated StringLength() attribute is then updated when we do 'Update model from database').

At a previous job, we also added base classes and interfaces to the entities, as you mentioned in your question.

---

Here's a snippet from our T4 template that checks for required columns and string lengths and adds the necessary validation attributes:

    ''' <summary>
    ''' <#=SummaryComment(primitiveProperty)#>
    ''' </summary><#=LongDescriptionCommentElement(primitiveProperty, 1)#>
    <EdmScalarPropertyAttribute(EntityKeyProperty:=<#=code.CreateLiteral(ef.IsKey(primitiveProperty))#>, IsNullable:=<#=code.CreateLiteral(ef.IsNullable(primitiveProperty))#>)>
    <DataMemberAttribute()>
<#+
  ' begin required attribute
  If Not ef.IsNullable(primitiveProperty) and not ef.IsKey(primitiveProperty) then
#>
<#+
    If ef.ClrType(primitiveProperty.TypeUsage) = GetType(Guid) Then
#>
    <GuidRequiredAttribute(ErrorMessage:="<#=FixName(code.Escape(primitiveProperty))#> is required")>
<#+
    Else
#>
    <RequiredAttribute(ErrorMessage:="<#=FixName(code.Escape(primitiveProperty))#> is required")>
<#+
    End If
#>
<#+
  End If
    If HasMaxLength(primitiveProperty.TypeUsage) then
    Dim d = MaxLength(primitiveProperty.TypeUsage)
#>
    <StringLengthAttribute(<#=d#>, ErrorMessage:="<#=FixName(code.Escape(primitiveProperty))#> cannot be longer than <#=d#> characters")>
<#+
    End If
#>

Answer 2

I know this is an old question, but I would have liked to come across this information when I started out. In our case where we have a win32 Delphi client in our multi-tier solution, I've used the templates (in C#) to generate the DTO classes in .Net, and the win32 counterparts.
This allows us to encapsulate the CRUD functionality on the client using largely auto-generated Delphi code:

procedure Delete;
class function DeleteDto(const _dESPATCHID: integer)  : boolean;
class function GetNextID  : integer;
class function Get(const _dESPATCHID: integer) : TDtoDESPATCH; overload;    
class function Collection(const __filterXml: string): TList<TDtoDESPATCH>;
function Load: boolean; overload;
function Populate(_primaryDict : TDictionary<string, Variant>) : boolean;
function Save : boolean; overload;

Change tracking from the client can also be automated, so each property setter will mark the changed property, to ensure only changed properties are updated. For example:

procedure TDtoDESPATCH.SetSCT_STATUS(const value : string);
begin
    if (self.IsLoaded) and (inherited SCT_STATUS <> value) then
      begin
        TrackChange('SCT_STATUS');
        self.Modified:= True;
      end;
    inherited SCT_STATUS := value;
end;

On the server side, another template takes care of all the CRUD operations in an auto-generated WCF service that's also exposed as an asmx web service. The Interface, WCF methods and all annotations are generated from the template.

// convert to entity
var _entity = _dto.ToEntity();
if(exists)
{
    Global.LogActivity(string.Format("{0} - profile {1}, updating DESPATCH: {2}", racID, profile, _dto.ChangedProperties ));
    // Attach the entity to the db
    db.DESPATCHes.Attach(_entity);
    // Change tracking
    ChangeTracking<DESPATCH>(_dto.ModifiedProperties, db, _entity);
}

In a scenario where WIN32 has to be part of the solution, hand coding all this would be a (worse) nightmare.

Answer 3

Well, the reason is that you can do anything with it. So, why don't have it? Of course the usage of T4 is very limited to some special cases, and most of the time it doesn't make sense to use it. On the other hand you can do funky stuff with it. For example you can define some user defined stuff. Let's say you have a Sort column in your table. Then you could define a query function where it automatically sorts every entry if this column exists. Maybe too trivial for an example, but there are tons of other weird architectures where it makes much more sense.

You can also make use of other code generation stuff, without EF. So it's certainly here for completeness and extendability.

Answer 4

T4 template replaces custom tool used in EFv1 to generate code behind file (.designer.cs file with all classes). The main advantage of T4 is that you can change it per project just by modifying text .tt file. In case of custom tool changes were mostly impossible.

With T4 you have complete control over entity classes generated from your EDMX. It is transformation of EDMX into C# or VB.NET files. The default template creates class files with features required by most of developers but if you need anything else you can simply go to your .tt file and add it.

Possibilities for changes are unlimited because EDMX file itself is extensible. On behind EDMX is just XML file and you can include your own custom XML elements in this file (it has some restrictions but it is possible - here is some example for SQL generation in model first approach). Once you have custom elements in EDMX you can use them in T4 template as decision logic for additional features you want to include in generated code. Entity designer is also extensible - you can create custom extensions which will be stored as custom elements in EDMX file. Both EDMX and Entity designer extensions are nicely described in book Entity Framework in Action.

Answer 5

I've used them quite a bit to generate code that is useful to us at a Datalayer level.

Altering whether they implement additional contracts (interfaces), adding methods, annotations and in the case of a non-layered application (and NOT recommended beyond this) adding property changed notification.

By adding some of these items to the generation at the Datalayer, I've been able to use a template in the Model project to generate the boiler plate code at this level too.

Bottom line, if you can safely get the computer to code for you, then it's well worth while. In our case 80% of basic plumbing work can be code genned - if it's incorrect, it's generally very easy to fix and regenerate.