If I use ASP.NET identity, am I stuck with EF?

Question

I've recently started learning ASP.NET, and after some reading, I've decided to try identity for authenticating users. I've read several articles about customizing the model, like implementing my own UserStore class to provide persistence if I wanted to store auth information elsewhere.

But I like classic SQL DB, what I don't like is Entity Framework code first approach (I don't know EF, I use LINQ to SQL for my ORM). Am I stuck with it? UserManager needs a IdentityDBContext, which is an EF context class, isn't it?

Am I supposed to:

1)Create a new Database for rest of my application logic, use LINQ for ORM - seems possible, but not like the RIGHT way to solve this

2)Put the rest of records into same database, create LINQcontext for them, and have effectively 2 contexts, each with half of classes - this seems kinda crazy

3)Stop being lazy, learn EF, add additional DBset properties into ApplicationDBContext and have 1 context for everything. But what if for example, I already have a database populated with users from whatever, and need to develop application for that? That seems like a Database first approach, and what then?

What should I do? Or is there other option?

I am using webforms (seemed easier to jump into), developing in VS2013.

Thanks in advance!

Answer 1

You're absolutely not required to use EF.

You should read this article for more information on how to implement your own data persistence mechanisms.