3

私はmvc3プロジェクトでlinqtosqlを使用しています。ドメインモーダルクラスファイルを生成する方法はいくつかあります。

  1. sqlmetal
  2. オブジェクトリレーショナルデザイナー
  3. ハンドコード

私は常にそれらのモデルクラスファイルを手動でコーディングします。sqlmetalまたはdesignerによって生成されたファイルが乱雑であるためです。あなたの意見は何ですか？それを行うための最良の方法は何ですか。

編集：

私はMVC3を使用しています。2ではありません。間違っているかもしれませんが、これが検証方法です。とにかくそれらすべてのクラスファイルを書くことになりますので、ツールを使用してそれらを生成するポイントは何ですか？

public class User
{ 
    [Required]
    public string Password { get; set; } 
    [Required, Compare("Password")] 
    public string ComparePassword { get; set; } 
}
4

2 に答える 2

4

複数のデータベース（1つのサーバー）に数百のテーブルがあります。テーブルを最初に開発し、各プロジェクト内のさまざまな名前空間を表すさまざまなフォルダーにあるさまざまなDBMLデザイナーファイルにテーブルをドラッグします。デザイナファイルはコンパイルしないようにマークされており、プロジェクト内のDBMLファイルから読み取ることによってコードを生成するカスタムビルドのT4テンプレートを使用します。これにより、生成されるコードを完全に制御できるため、インターフェイスの実装などを行うことができます（IAuditableは、CreatedBy、CreatedDate、ModifiedBy、ModifiedDateがある1つの例です）。バディクラスに頼ることなく、この方法でLinqedオブジェクトにSystem.ComponentModel.DataAnnotationsを配置することもできます。。データベースからのDBMLの更新を担当する2番目のT4テンプレートがあるので、テーブルに3つの部分のプレフィックス（db.schema.tbl）が付いていることを確認できるため、削除して再度追加する必要はありません。デザイナー。XMLは、dbスキーマの読み取りとDBMLの更新に基づいて変更されます。また、GetByID（）などのいくつかの一般的なクエリ操作を持ち、コミットと監査ログを処理する各POCOのリポジトリ/マネージャーオブジェクトを生成します。これらのマネージャーは、各テーブルに対して作成する必要のあるすべてのカスタムクエリで拡張され、DataContextを所有します。このデザインは「Mommy-may-I？」と呼ばれることもあります。テーブルにリンクされたオブジェクトがそのマネージャーにすべてを実行するように要求する必要があるアプローチ。

これは、L2Sを実行するための非常に用途が広く、洗練された方法であることがわかりました。これにより、バックエンドの開発が簡単になり、ユーザーエクスペリエンスに焦点を当てることができます。唯一の欠点は、名前空間間で関連付けを行う場合、それらを部分クラスに手動で追加する必要があることです。そうしないと、関連付けを描画するためにその外部テーブルを別のDBMLに追加する必要があります。これは実際には、名前空間の特異性について実際に考え、余分な名前空間を削減するほど悪いことではありません。このようにT4を使用することは、DRYを開発するための優れた方法です（繰り返してはいけません）。テーブル定義は、構造を変更する必要がある唯一の場所であり、すべてが伝播します。検証は、POCOという1つの場所で行われます。クエリは、マネージャーの1か所で行われます。同様のことをしたい場合は、ここから始めるのが良いでしょう。

于 2011-07-13T03:45:22.303 に答える
0

Designerで生成されたクラスが乱雑であっても、それはあなたにとって何が重要ですか？

敢えて言うと、デザインファイルの1つを開く必要はまったくありません。

モデルで定義されているエンティティのいずれかを拡張する必要がある場合、それらはすべて部分クラスであるため、同じ名前の独自の部分クラスを作成して、自分のものを実装することができます...

L2Sを使用するときは、デザイナーを使用します。

于 2011-07-13T00:39:28.097 に答える