T4を使ってEFのエンティティを変更するのはなぜですか？

Question

EFで 'ADO.NET EntityObject Generator'を使用する正当な理由は何ですか？あなたが知らない場合は、edmxからエンティティの構築を行うT4ファイルを生成します。エンティティの生成方法を変更するには、T4ファイルを変更します。

私の質問は、エンティティが派生した（インターフェイスを実装する）基本クラスを変更し、エンティティやコンテキストオブジェクトや名前付け規則のアクセシビリティを変更する以外、これはどのような用途ですか？ EFと部分クラスの既存の機能を考慮する。

私は、テーブル/列の説明データベースから2

1. グラブを作ってみた光wieght DTOのを生成し、自動マッピングを行うエンティティやプロパティ
2. の概要を取り込みます。

1（それはそうでしたが）

2 EDMXそのものではない、それが唯一のモデルにコメントを更新考慮あまりにも多くの仕事のように思えるこれも、便利ですか？

Answer 1

T4テンプレートでいくつかのことを行いました。最初のものは、生成されたコードを1つの大量ファイルではなく、ファイルごとに1つのクラスに分割することです。これにより、エンティティをナビゲートして参照するのが簡単になります。

さらに重要なのは、StringLengthやRequiredなどのデータ注釈検証属性を自動的に生成することです。これにより、単一の関数呼び出しでエンティティを検証できるようになり、検証属性が常にデータベースと同期することが保証されます（たとえば、DB内の列の長さを変更すると、生成されるStringLength（）属性は「データベースからモデルを更新する」ときに更新されます）。

以前の仕事では、質問に記載したように、エンティティに基本クラスとインターフェイスも追加しました。

''' <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

まあ、理由はあなたがそれで何でもできるということです。

---

ここで必要な列と文字列の長さをチェックし、必要な検証属性を追加し、当社のT4テンプレートからの抜粋です。だから、なぜそれを持っていないのですか？もちろん、T4の使用法はいくつかの特殊なケースに限られており、ほとんどの場合、T4を使用することは意味がありません。一方、あなたはそれでファンキーなことをすることができます。たとえば、ユーザー定義のものを定義することができます。たとえば、テーブルにSortという列があるとします。次に、この列が存在する場合、すべての項目を自動的にソートする照会機能を定義することができます。例はあまりにも些細かもしれませんが、はるかに理にかなった奇妙なアーキテクチャーがたくさんあります。

また、EFなしで他のコード生成物を利用することもできます。したがって、完全性と拡張性については確かにここにあります。

Answer 3

T4テンプレートは、コードビハインドファイル（すべてのクラスを含む.designer.csファイル）を生成するためにEFv1で使用されるカスタムツールを置き換えます。 T4の主な利点は、テキスト.ttファイルを変更するだけでプロジェクトごとに変更できることです。カスタムツールの場合、変更はほとんど不可能でした。

T4では、EDMXから生成されたエンティティクラスを完全に制御できます。それはEDMXのC＃またはVBへの変換です。NETファイル。デフォルトのテンプレートは、ほとんどの開発者が必要とする機能を持つクラスファイルを作成しますが、必要な場合は.ttファイルに移動して追加するだけです。

EDMXファイル自体が拡張可能であるため、変更の可能性は無制限です。後でEDMXはXMLファイルであり、独自のカスタムXML要素をこのファイルに含めることができます（いくつかの制限がありますが、hereはモデルの最初のアプローチでのSQL生成の例です）。 EDMXでカスタム要素を作成したら、生成されたコードに含める追加機能の決定ロジックとしてT4テンプレートでカスタム要素を使用できます。エンティティデザイナも拡張性があり、EDMXファイルにカスタム要素として格納されるカスタム拡張を作成できます。 EDMXとEntityの両方のデザイナの拡張機能は、Entity Framework in Actionという本でうまく説明されています。

Answer 4

私はこれが古い質問であることを知っていますが、私が始めたときにこの情報に遭遇したかったでしょう。 私たちの多階層ソリューションでwin32 Delphiクライアントを使用している私の場合、私は.NETでDTOクラスを生成するためにテンプレート（C＃で）を使い、win32で対応しています。
これは、私たちは、主に自動生成されたDelphiのコードを使用して、クライアント上のCRUD機能をカプセル化することができます：クライアントからの追跡

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; 

変更も自動化することができるので、各プロパティのセッターが変更されたプロパティをマークします変更されたプロパティのみが更新されるようにします。たとえば ：サーバー側で

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; 

、別のテンプレートは、ASMX Webサービスとして公開されています自動生成されたWCFサービスのすべてのCRUD操作の世話をします。インタフェース、WCFメソッド、およびすべての注釈はテンプレートから生成されます。 WIN32が溶液の一部でなければならないシナリオで

// 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); 
} 

、このすべてをコーディング手は（悪い）悪夢であろう。

Answer 5

データレイヤーレベルで私たちにとって有益なコードを生成するためにそれらをかなり使いました。

追加のコントラクト（インターフェイス）を実装するかどうか、メソッドや注釈を追加するかどうかを変更し、さらにレイヤードアプリケーションの場合はこれを推奨しません。

Datalayerの世代にこれらのアイテムを追加することで、Modelプロジェクトのテンプレートを使用してこのレベルでボイラープレートコードを生成することができました。

最終的に、コンピュータを安全にコードすることができれば、それは価値があります。我々のケースでは、基本配管工事の80％がコード化されている可能性があります - それが間違っていれば、一般的に修正して再生するのが非常に簡単です。