ASP.NET IDを統合するためのベストプラクティス - 彼らは存在しますか?
-
20-12-2019 - |
質問
私は新しいウェブサイトとASP.NET IDを使用しています、そして、切り離された方法でこれを行う方法の例はたくさんありません。 Domain ModelのDomainUser
クラスがMicrosoft.AspNet.Identity.EntityFramework.User
から継承する必要がありませんので、このようなクラスを作成しました。
public class IdentityUser : User
{
public virtual DomainUser DomainUser { get; private set; }
}
.
ASP.NET IDで必要なDbSet
sを、ドメインモデルとして同じ派生DbContext
クラスに移動しましたこの回答に示すように。 Fluent APIを介してIdentityUser
をDomainUser
にリンクしています。
modelBuilder.Entity<IdentityUser>().HasRequired(iu => iu.DomainUser).WithRequiredPrincipal();
.
これにより、DomainUser
クラスで定義されている動作と認証の懸念をほとんど区別できます。これはそれらを1つのクラスに組み合わせるよりも優れていますが、まだ醜い感じます。私は私のドメインプロジェクトで必要なASP.Net Identityアセンブリへの参照がまだあります。ナビゲーションプロパティを可能にするが、それが対応していると感じ始めるために、IdentityUserクラスのみを保持しているもう1つのプロジェクトを作成することができました。
私は、それが厳密な結合をもたらすことなく、アイデンティティをドメインまでリンクするより良い、よりきれいで、よりモジュールな方法があるべきであるように感じます。
誰もがこれを扱うより良い方法を思いつくのですか?私はASP.NET IDプロジェクトに関わる人々の注意を向上させることを望んでいます( hao kung et al)ここで方向を提供する。
解決 2
事実は、IdentityUserから継承するつもりであれば、asp.NET ID関連のアセンブリが乗車に沿って来ているということです。IDをASP.NETから分離することはできません。質問の元の例では、ほとんどの場合、ドメインプロジェクトでIdentityUser
を使用している場合は、IdentityUser
から継承するだけではおそらく最適です。
本当にASP.NET関連のアセンブリを真に空いている場合は、Webプロジェクト内のID関連クラスを残して、ドメインプロジェクトに別のUser
モデルを作成できます。href="https://stackoverflowflow.com/questions/28974687/where-should-ef-migrations-my-class-library-project-or-my-asp-net-project/2897510666">ここ。
他のヒント
ASPのデカップリングに関する議論。ここでのネットアイデンティティ。そして、オープンソースProject SimpleSecurity
で実装されている方法についての例を見つけることができます。