tag - ¿Cómo sabe una nueva aplicación ASP.NET MVC 5 cómo crear una base de datos y cómo accede el Controlador de Cuentas a la base de datos?

web forms c#

Question

Creé una aplicación ASP.NET MVC 5 utilizando Visual Studio 2013 Update 2 . En la aplicación, tengo un controlador de cuenta. Es diferente de lo que estoy acostumbrado y no contiene una instancia de dbcontext .

public class AccountController : Controller
{
private ApplicationUserManager _userManager;
public AccountController()
{
}
public AccountController(ApplicationUserManager userManager)
{
UserManager = userManager;
}
public ApplicationUserManager UserManager {
get
{
return _userManager ?? HttpContext.GetOwinContext().GetUserManager<ApplicationUserManager>();
}
private set
{
_userManager = value;
}
}

Mi web.config que se crea de manera predeterminada tiene una cadena de conexión como esta:

 <connectionStrings>
<add name="DefaultConnection" connectionString="Data Source=(LocalDb)/v11.0;AttachDbFilename=|DataDirectory|/aspnet-WebApplication3-20140417072624.mdf;Initial Catalog=aspnet-WebApplication3-20140417072624;Integrated Security=True"
providerName="System.Data.SqlClient" />
</connectionStrings>

¿Puede alguien explicarme cómo sabe la aplicación para crear una base de datos para esta aplicación cuando se inicia por primera vez?

Además, en los siguientes inicios, ¿utiliza Entity Framework para acceder a las tablas de identidad para realizar la autenticación?

Answer 1

Seguramente estaría en el ApplicationUserManager , supongo que este es un servicio que utiliza el contexto db para administrar los usuarios de la aplicación.

Puede hacer clic derecho en esta clase y hacer clic en Go to definition y seguir haciéndolo hasta que pueda ver la clase que inicializa la base de datos.

Además, en MVC 4, la inicialización se realiza en un atributo de filtro. Así que mira en la carpeta Filter si hay uno. Sé que no es MVC 5. Pero podría ser aplicable.

Answer 2

1) ¿QUÉ PASA AQUÍ?

Cuando crea una nueva aplicación MVC 5 y elige " Cuentas de usuario individuales ", se incluye un nuevo proveedor de identidad ASP.NET que utiliza Entity Framework 6 Code-First .

Microsoft ha adoptado EF-Code-First para hacer que la identidad sea lo más personalizable posible.

Cuando se accede a Identity por primera vez, Entity Framework comprueba si existe la base de datos. A menos que se configure de otra manera, usa la "DefaultConnection" para encontrar la base de datos de identidad. Si la base de datos no existe cuando se llama a Identity, EF creó automáticamente la base de datos.

Observe que su cadena de conexión contiene

`AttachDbFilename=|DataDirectory|/aspnet-WebApplication3-20140417072624.mdf`

Si abre su carpeta de datos de aplicación, debe tener un archivo aspnet-WebApplication3-20140417072624.mdf .

Si hace doble clic en este archivo .mdf , el Explorador del servidor VS2013 abrirá su base de datos. Si ya ha intentado acceder a cualquier funcionalidad de identidad, creará estas tablas:

• _MigrationHistory
• ASPNetRoles
• ASPNetUserClaims
• ASPNetUserLogins
• ASPNetUsers

De forma predeterminada, su aplicación está configurada para usar SQL Server Compact (archivo MDF) por lo que no es necesario tener una instancia real de SQL Server en ejecución. Todo esto es personalizable. El nombre de su archivo MDF, el esquema de Identity Database, la elección de SQL Compact frente a una instancia real de SQL Server . Cambie su cadena de conexión, o cree una nueva y pase esta nueva conexión a su contexto.

2) ¿DÓNDE ESTÁ MI CONTEXTO?

Todo esto está muy bien, pero una pregunta importante que hizo fue básicamente " ¿Dónde está mi contexto? ", Y las preguntas implícitas igual de relevantes sobre cómo puede personalizar aún más su base de datos o alterar la lógica de validación.

Notará que su proyecto hace referencia a Microsoft.AspNet.Identity.EntityFramework . Este ensamblado es una implementación de IdentityDBContext<TUser> y la implementación de UserManager Class.

Abra su AccountController , y observe que el constructor tiene UserManager objeto UserManager pasado que a su vez tiene un new UserStore objeto new UserStore pasado, que pasa un ApplicationDbContext .

 public AccountController()
: this(new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(new ApplicationDbContext())))

ApplicationDbContext está definido en su Carpeta de Modelos . Dentro de esa carpeta, encontrará un archivo IdentityModels.cs . Ábrelo y verás

public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
public ApplicationDbContext()
: base("DefaultConnection")
{
}
}

Aquí es donde se le asigna su contexto de identidad. puede cambiar el nombre de conexión pasado al constructor ApplicationDbContext , o definir y usar un contexto diferente en su controlador de cuenta.

3) ¿CÓMO PERSONALIZO MI ESQUEMA DE IDENTIDAD?

Otra clase definida en el archivo IdentityModels.cs es la clase ApplicationUser que hereda de la clase IdentityUser .

public class ApplicationUser : IdentityUser
{
}

Cualquier propiedad que agregue a esta clase se mantendrá en su Tabla de ASPNetUsers . El resto del esquema se define en la clase IdentityDbContext . Entonces, si bien puede agregar más tablas (por ejemplo, Privilegios) a su Esquema de identidad agregando un DBSet a la Definición de contexto,

public DBSet<Privileges> { get; set; }

También es posible modificar otras tablas (Roles, Reclamaciones, etc.), pero mucho más complicado. Por ejemplo, para personalizar la tabla Roles , debería implementar un NewIdentityRole hereda de IdentityRole y agregar su relación anulando el método OnModelCreating() para su Contexto.

Este artículo sobre Customizing Roles Tables hace un buen trabajo al describir los pasos involucrados. Incluso aquí, encontrará que hay problemas importantes invertidos en simplemente AGREGAR nuevas columnas. La eliminación de tablas o columnas del esquema original creado en la clase IdentityDbContext es probablemente tan problemático como crear su propia implementación de la clase IdentityDbContext .

Answer 3

Como Melina señaló, la pregunta original hacía referencia al modelo actual de ASP.NET Identity 2.x.

La respuesta de Dave Alperovich brindó información valiosa sobre los conceptos detrás de ASP.NET Identity, aunque los ejemplos fueron tomados de ASP.NET Identity 1.x, que fue reemplazado en 2014.

Callum Linington brinda la respuesta "enséñale a un hombre a pescar". Siguiendo su consejo, es fácil ver que la clase 2.x "ApplicationUserManager" se deriva de un "UserManager" de estilo 1.x.

La respuesta es básicamente que el "ApplicationUserManager", que se inyecta como parámetro cuando se crea "AccountController", se conecta al almacén de datos de identidad en su propio constructor:

var manager = new ApplicationUserManager(new UserStore<ApplicationUser>(context.Get<ApplicationDbContext>()));

Tenga en cuenta que este código 2.x "oculto" es muy similar al código 1.x como se indica arriba:

public AccountController()
: this(new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(new ApplicationDbContext())))