2

タイトルと次のテキストが明確であることを願っています。正しい用語にあまり詳しくないので、間違っている場合は修正してください。初めてLinq ORMを使用していますが、以下に対処する方法を考えています。

2 つの DB テーブルがあるとします。

User
----
Id
Name


Phone
-----
Id
UserId
Model

Linq コード ジェネレーターは、一連のエンティティ クラスを生成します。

次に、これらの Linq クラスをラップする独自のクラスとインターフェイスを作成します。

class DatabaseUser : IUser
{
    public DatabaseUser(User user)
    {
        _user = user;
    }

    public Guid Id 
    {
        get { return _user.Id; } 
    }

    ... etc
}

ここまでは順調ですね。

これで、ユーザーの電話を簡単に見つけることができますPhones.Where(p => p.User = user)が、API の利用者は、データを取得するために独自の Linq クエリを作成する必要はないはずです。そのため、このクエリを関数またはプロパティのどこかにラップする必要があります。

問題は、この例で Phones プロパティを IUser に追加するかどうかです。

言い換えれば、私のインターフェイスは具体的に私のデータベース オブジェクトをモデル化する必要がありますか (この場合、Phones は IUser に属しません)、または実際には、ユーザーに概念的に関連付けられている関数とプロパティのセットを提供するだけです (この場合、それはですか）？

どちらのビューにも欠点があるようですが、問題に対する標準的なアプローチがあるかどうか疑問に思っています。または、あなたが共有できる一般的な知恵の言葉.

私の最初の考えは、拡張メソッドを使用することでしたが、実際にはこの場合は機能しません。

4

4 に答える 4

2

インターフェイスの背後にあるLINQtoSQLエンティティを抽象化しようとするいくつかのひどい経験があります。少し前のことですが、記憶からの主な問題は、それが完全に関連付けを壊すことでした。たとえば、Customer->関係がある場合、sのコレクションを使用して、Orderそれをとして公開することになります。つまり、オブジェクトの内部コレクションをsとしてキャストするには、厄介なマッピングを行う必要があります。ICustomerIOrderCustomerOrderIOrder

IOrder次に、が渡されたときに、それをにキャストできると想定する必要がありOrderます。そうでなければ、LINQtoSQLはそれを処理できませんが、そもそもそこにインターフェースを持つという点を打ち負かします。

エンティティクラスを抽象化しすぎないようにすることを強くお勧めします。LINQtoSQLは実際にはエンティティクラスに魔法をかけません。DataContextは永続性のライフサイクルを処理するため、テスト可能です。

インターフェイスの背後に隠そうとしている側面は、たとえばリポジトリスタイルのクラスを使用したDataContextとの相互作用です。

public interface IPhoneRepository 
{
    IEnumerable<Phone> GetPhonesForUser(User user);
}

public class L2SPhoneRepository : IPhoneRepository
{
    private readonly MyDataContext context;

    public L2SPhoneRepository(MyDataContext context)
    {
        this.context = context;
    }

    public IEnumerable<Phone> GetPhonesForUser(User user)
    {
        return context.Phones.Where(p => p.User == user);
    }
}
于 2010-03-19T12:43:31.910 に答える
0

Phones プロパティを IUser に追加して null 可能にする必要があるため、Phone を持たないユーザーの場合は null になります。

API のコンシューマーにクエリを記述させたくないため、GetUser().. などの関数を実装する必要があります。

これは、Asp.net の記事 abt n 層アプリケーションの優れたリストです。

http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=416

于 2010-03-19T12:48:15.180 に答える
0

インターフェイスは、オブジェクトの使用方法をモデル化する必要があります。抽象化しようとしているので、消費者はDBに問い合わせる必要はありません。プロパティにするか、別の関数呼び出し (つまり、GetPhones()) にするかは、完全にあなた次第です。物事を完全にラップしているので、オブジェクトをロードする深さ/遅延についていくつかの選択を行う必要があります。

于 2010-03-19T12:23:01.010 に答える
0

Linq2Sql 関連のものは、データ アクセス コードの実装の詳細であると考える傾向があり、データベースの実際の構造と同様に、必ずしもシステムの他の部分に公開する必要はありません。

あなたの API が他の人によって消費される場合、それはまとまりがあり、使いやすく、消費者が知る必要のないもので散らかっていてはなりません。ユーザーとその電話を扱っている場合、DataContext や (うーん) DataSet について知りたくありません。

また、コードの大部分を L2S とデータベースに関係なく保持することで、テスト、スキーマの変更 (ユーザー テーブルはすべての変更の履歴を保持する必要があります)、または ORM の完全な変更を行うのが簡単になります。 .

于 2010-03-19T13:02:22.657 に答える