1

これは少し奇妙な質問かもしれませんが、私が持っているものは現在機能していますが、私には少し奇妙に感じられ、設計/アーキテクチャが貧弱なためではないかと思います. ここでの考えは大歓迎です。

初期の設計は、私が他の誰かから継承したコード ベースにあります。linq-to-sql クラスがあります (dbml のデザイナー ファイルで自動生成されます)。


[global::System.Data.Linq.Mapping.TableAttribute(Name="dbo.ARCustomers")]
public partial class ARCustomer : INotifyPropertyChanging, INotifyPropertyChanged
{
    // variables
    // extensibility method defs
    // ctor
    // properties
    // etc.
}

次に、自動生成されたクラスの拡張バージョンである別のクラス クラスが呼び出されArCustomerます (小文字の "r" に注意してください)。拡張とは、LINQ クラスのすべてのプロパティに加えて、いくつかのロジックを設定する必要があるいくつかのプロパティを備えていることを意味します。

ARCustomerを取得して に変換したいコードの場所がたくさんありますArCustomer。ArCustomerそこで、クラスに拡張メソッドを書きました (これが奇妙に感じました) 。


public static ArCustomer FromDatacontextObject(this ArCustomer customer, ARCustomer datacontextObject)
{
    var arCustomer = new ArCustomer();
    arCustomer.Id = datacontextObject.ProjectID;
    // more of the same

    // now populate the other fields that don't exist on the datacontextObject

    return arCustomer;
}

というように呼ばれています。


var customerfromDb = accountReceivableRepository.GetCurCustomer(arId);
ArCustomer customer = new ArCustomer();
customer = customer.FromDatacontextObject(customerfromDb);

これは私には間違っているように感じますが、頭の中でより良い代替案を知りません. (拡張プロパティを含む部分クラスは機能しますか? コンストラクターにそれらを設定しますか?) または多分それは問題ありません...私はいくつかのことに興味があります...

  1. これが間違っている/奇妙である/悪いと感じているのは正しいですか?
  2. 具体的には、私が実装したソリューションに見られる短所は何ですか? 1つは、2つのクラスを区別してどちらがどちらであるかを理解しようとして、頭をかきむしりすぎているように感じます。
  3. 彼らの長所はありますか？
  4. より良い解決策はありますか (そしてなぜそれらが優れているのか)?

(無関係 - この種の質問がスタック オーバーフローに問題ないことを願っています。主観的である可能性があるミニ コード レビューを求めているように感じます。一方で、いくつかの具体的な質問をしようとしましたが、そうしなければならないと感じました。このような状況に遭遇したのは開発者だけではありません (「私はあるオブジェクトを持っていて、それを別のオブジェクトに変換する必要があります」)。そのため、スレッドを開いたままにしておくことで何かが得られることを願っています)。

みんなありがとう！

4

3 に答える 3

2

あなたの本能はあなたによく役立ちます。

C# コンパイラでは、技術的には同じ名前 (大文字と小文字のみが異なる) を持つ 2 つのクラスを使用できますが、これはお勧めできません。また、CLS に準拠していません。

あなたがすでに述べた正確な理由から、それは悪い考えです：読みやすさ。読みやすさの重要性を過小評価しないでください。個人的には、コード品質の私の一番の尺度です。読みやすいコードはバグが少ない傾向があり、デバッグ/保守が容易です。

LINQ to SQL によって生成されたクラスは、既に部分クラスです。別のコード ファイルを追加して、必要な追加部分を定義できます。そして、これはあなたが説明していることを達成するための好ましい方法です. 保守と理解が容易になります。

または、ARCustomer を含む「ViewModel」クラスを作成することもできます。(これはアーキテクチャによって異なります)。

于 2011-08-15T02:01:56.737 に答える
2

拡張メソッドを変更してデータベース オブジェクトを拡張すると、より自然な API IMO になります。

public static ArCustomer ToDomainObject(this ARCustomer datacontextObject)
{
   var arCustomer = new ArCustomer();
   arCustomer.Id = datacontextObject.ProjectID;
   // more of the same

   // now populate the other fields that don't exist on the datacontextObject

   return arCustomer;
}

データアクセスコードは次のようになります

var customerfromDb = accountReceivableRepository.GetCurCustomer(arId);
ArCustomer customer = customerfromDb.ToDomainObject();
于 2011-08-15T00:26:03.507 に答える