0

Entity Framework (MVC4 および EF5RC) を使用して、ビュー モデル内に未使用のプロパティを配置することなく、多対多の関係を作成しようとしています。

私はUserクラスを持っています：

public class User
{
    public Guid Id { get; set; }
    public string[] Roles { get; set; }
    public string Name { get; set; }
 }

そしてRoleクラス：

public class Role
{
    public Role()
    {
        Users = new List<User>();
    }

    public int Id { get; protected set; }

    public string Name { get; set; }
    public string Description { get; set; }

    public IList<User> Users { get; set; }       
}

私が達成したいのは、いくつかのロール (この時点ではロールの文字列名) に属するユーザーを持つことです。それらは複数のロールに属することができます。各ロールには複数のユーザーを含めることができます。

Entity Frameworkが満足して保存できるように、ロールにユーザーのリストとユーザーにロールのリストを配置する必要はありません。

私はmodelBuilderのものを使用しようとしています（Entity Framework Code Firstで階層データの関係を定義するなどのいくつかの例に従いました）。喜びもなく。

余分なプロパティを避けたい理由は、null リストや、さらに悪いことに他のユーザーをリストする役割のリストを持つのは気分が悪いからです。ドメイン モデルをクリーンにして、リポジトリを操作するために曲がる必要がないようにしたいと考えています。

4

1 に答える 1

1

Entity Frameworkを使用することを選択した場合、EntityFrameworkが満足できる方法で使用する以外に選択肢はありません。しかし、なぜこれがポイントになるのでしょうか。そもそも、単純に機能するドメインモデルに焦点を当てるべきだと思います。それはビジネスルールを適用し、EFとスムーズに連携します。

第二に、選択肢があります：私は何を公開しますか？承認ロジックを含むアセンブリの内部に、EF（コンテキスト+エンティティ）を含むすべてのものを保持できます。したがって、エンティティクラスではなく、専用クラス（必要に応じてDTO）を公開します。ロールUser内の他のユーザーを公開しないため、このようなクラスになる可能性があります。明らかに、EFが簡単に設定できるクラスではありません。

アセンブリには、クライアントコードに必要なデータとアクティビティのみを提供し、それ以上のものを提供しないいくつかのメソッドを公開するファサードまたはサービスクラスが必要です。内部的には、エンティティクラスとDTOの間でマッピングされます。

最近、私はこれらの原則に大まかに従った認証ライブラリに取り組んでいますが、もちろん、モデルにはいくつかの違いがあります。

于 2012-07-30T23:13:17.980 に答える