POCO's with the new ASP.NET Identity and MVC 5

问题:

With the new version of VS 2013 RTM and asp.net mvc 5.0, I’ve decided to try out a few things...

Needless to say, a lot has changed. For example, the new ASP.NET Identity is a replacement of the old Membership and (less old) SimpleMembership APIs.

In all previous applications I’ve built, I never had the chance to work with Membership or with SimpleMembership. I’ve always ended up creating my own Login() method which would convert a submitted ViewModel to a POCO (using automapper) which in turn, would use some sort of repository to lookup the user and password.

In return, I would obtain a User POCO that would later be converted (using automapper) to a smaller UserSession POCO. The smaller UserSession would be place in Session.

Of course, I would still use FormsAuthentication to create an Encrypted Ticket and use FormsAuthentication.SignOut() when the user wanted to logoff.

But I never fully took advantage of what Membership (or SimpleMembership) had to offer.

I never had my POCOs implement some sort of Interface nor did I have to add a reference to the Microsoft’s libraries inside my POCO class library. In other words, I never had a strong dependency on anything.

My question is the following:

With the examples I see, I keep seeing that the new ASP.NET Identity creates (via code first) some tables and fields. For example, the AspNetUsers table holds an Id field as a string. Of course, I’m sure there is a way to overcome this and will eventually see examples, but why would anyone NOT want to build pure POCO classes and have total control of what and how things are created?

Unless I’m confused (which has a high probability) can anyone explain why I would want to use the new ASP.NET Identity API (or more importantly, use the new Microsoft.AspNet.Identity.EntityFramework) to create my tables?

What are the Pros and Cons in wanting to use this as opposed to the POCO style of things?

Perhaps I should be asking this in a different question, but I’m also trying to understand how can I benefit the new claims-based Identity while using POCOs instead of Entities generated with ASP.NET Identity.

Feel free to point me in the right direction for clarifications.

回答1:

you can create your own UserManager completely,wich i don't recommand unless you have a strong knowledge about how it works.you can wrap the existing UserManager and make you application rely on an interface or just use it directely and benefit from what microsoft has put in it.if you don't like EF you can create your own Store to use another Database. the new ASP.NET Identity is extensible enough,i agree that is kinda Hard if you want to take full controle and customize everything,but i recommand taking time to understand the most of it so you can choose when to use or not.most of time it's enough to use the existing UserManager.

回答2:

You want the UserManager from Microsoft.AspNet.Identity to do your security part such your users do not have to trust that you can handle your security information correctly.

Identity.Framework is just a datastore for the Identity stuff, you could create your own store instead if you dont want EF. I have created one that just stores information directly in a xml file. But I always come back to using Identity because I dont want to deal with encrypting and making sure I am up to date with stuff in the security department.