VS 2013 RTM と asp.net mvc 5.0 の新しいバージョンで、いくつか試してみることにしました...
言うまでもなく、多くのことが変わりました。たとえば、新しいAPI は、古い APIと (あまり古くない) APIをASP.NET Identity置き換えるものです。MembershipSimpleMembership
これまでに作成したすべてのアプリケーションで、Membership や SimpleMembership を使用する機会はありませんでした。私は常にLogin()、提出された ViewModel を (automapper を使用して) POCO に変換する独自のメソッドを作成することになりました。POCO は、何らかのリポジトリを使用してユーザーとパスワードを検索します。
その見返りに、後で (automapper を使用して) より小さな UserSession POCO に変換される User POCO を取得します。小さい UserSession は Session に配置されます。
もちろん、ユーザーがログオフしたいときFormsAuthenticationに作成して使用するために引き続き使用しますEncrypted Ticket。FormsAuthentication.SignOut()
しかし、提供されたものを十分に活用したことはありませんでしMembership (or SimpleMembership)た。
POCO にある種のインターフェイスを実装させたことも、POCO クラス ライブラリ内に Microsoft のライブラリへの参照を追加する必要もありませんでした。つまり、何かに強く依存したことはありません。
私の質問は次のとおりです。
私が見た例では、新しい ASP.NET Identity が (最初にコードを介して) いくつかのテーブルとフィールドを作成することがわかります。たとえば、AspNetUsersテーブルはIdフィールドを として保持しますstring。もちろん、これを克服する方法はあると確信しており、最終的には例を見ることになるでしょうNOT want to build pure POCO classes。
私が混乱していない限り (可能性が高い) Microsoft.AspNet.Identity.EntityFramework、テーブルを作成するために新しい ASP.NET Identity API を使用する (またはさらに重要なことに、 new を使用する) 理由を誰か説明できますか?
Pros and ConsPOCOスタイルのものとは対照的に、これを使用したいのは何ですか?
おそらく別の質問でこれを尋ねる必要がありますが、ASP.NET ID で生成されたエンティティの代わりに POCO を使用しているときに、新しいクレームベースの ID にどのように役立つかを理解しようとしています。
明確にするために、私を正しい方向に向けてください。