Je construis ma première application MVC 5/Entity Framework. J'ai utilisé la première méthode de base de données pour extraire mes données d'un serveur SQL existant. La base de données SQL existante reçoit ses données à partir d'une application .net de formulaires Web distincte.
À l'avenir, la nouvelle application MVC et l'application de formulaires Web existante partageront la base de données.
J'utilise Identity pour créer des comptes d'utilisateurs dans l'application MVC. Donc, à ce stade, j'ai 2 connexions de données dans mon application MVC. Un pour les comptes d'utilisateur et l'autre pour le serveur SQL existant.
Est-ce la meilleure façon de mettre en place le projet MVC? À l'avenir, pourrai-je accéder à la base de données d'utilisateurs à partir de l'application de formulaires Web?
Je suis un débutant et je veux m'assurer que je l'installe correctement.
Les tables d'utilisateurs seront-elles ajoutées au serveur SQL existant ou sont-elles cette base de données d'utilisateurs une base de données complètement séparée?
Vous n'avez pas besoin de deux bases de données - vous pouvez créer des tables d'identité dans votre base de données existante.
Identité ASP.Net utilise Entity Framework Code First . Par conséquent, avant d'exécuter votre application pour la première fois, vous souhaitez mettre à jour Connection String de la même manière qu'une base de données existante, qui se trouve normalement dans ApplicationDbContext .
Si vous avez déjà deux bases de données distinctes et souhaitez les fusionner, vous souhaitez utiliser des outils tels que RedGate - Comparaison SQL et Comparaison de données.
La fusion de deux bases de données est totalement hors de question; s'il vous plaît veuillez créer une question distincte si vous en avez une.
Exécutez ce script SQL sur la base de données.
/****** Object: Table [dbo].[AspNetRoles] Script Date: 15-Mar-17 10:27:06 PM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[AspNetRoles](
[Id] [nvarchar](128) NOT NULL,
[Name] [nvarchar](256) NOT NULL,
CONSTRAINT [PK_dbo.AspNetRoles] PRIMARY KEY CLUSTERED
(
[Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
/****** Object: Table [dbo].[AspNetUserClaims] Script Date: 15-Mar-17 10:27:06 PM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[AspNetUserClaims](
[Id] [int] IDENTITY(1,1) NOT NULL,
[UserId] [nvarchar](128) NOT NULL,
[ClaimType] [nvarchar](max) NULL,
[ClaimValue] [nvarchar](max) NULL,
CONSTRAINT [PK_dbo.AspNetUserClaims] PRIMARY KEY CLUSTERED
(
[Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
/****** Object: Table [dbo].[AspNetUserLogins] Script Date: 15-Mar-17 10:27:06 PM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[AspNetUserLogins](
[LoginProvider] [nvarchar](128) NOT NULL,
[ProviderKey] [nvarchar](128) NOT NULL,
[UserId] [nvarchar](128) NOT NULL,
CONSTRAINT [PK_dbo.AspNetUserLogins] PRIMARY KEY CLUSTERED
(
[LoginProvider] ASC,
[ProviderKey] ASC,
[UserId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
/****** Object: Table [dbo].[AspNetUserRoles] Script Date: 15-Mar-17 10:27:06 PM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[AspNetUserRoles](
[UserId] [nvarchar](128) NOT NULL,
[RoleId] [nvarchar](128) NOT NULL,
CONSTRAINT [PK_dbo.AspNetUserRoles] PRIMARY KEY CLUSTERED
(
[UserId] ASC,
[RoleId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
/****** Object: Table [dbo].[AspNetUsers] Script Date: 15-Mar-17 10:27:06 PM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[AspNetUsers](
[Id] [nvarchar](128) NOT NULL,
[Email] [nvarchar](256) NULL,
[EmailConfirmed] [bit] NOT NULL,
[PasswordHash] [nvarchar](max) NULL,
[SecurityStamp] [nvarchar](max) NULL,
[PhoneNumber] [nvarchar](max) NULL,
[PhoneNumberConfirmed] [bit] NOT NULL,
[TwoFactorEnabled] [bit] NOT NULL,
[LockoutEndDateUtc] [datetime] NULL,
[LockoutEnabled] [bit] NOT NULL,
[AccessFailedCount] [int] NOT NULL,
[UserName] [nvarchar](256) NOT NULL,
CONSTRAINT [PK_dbo.AspNetUsers] PRIMARY KEY CLUSTERED
(
[Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
ALTER TABLE [dbo].[AspNetUserClaims] WITH CHECK ADD CONSTRAINT [FK_dbo.AspNetUserClaims_dbo.AspNetUsers_UserId] FOREIGN KEY([UserId])
REFERENCES [dbo].[AspNetUsers] ([Id])
ON DELETE CASCADE
GO
ALTER TABLE [dbo].[AspNetUserClaims] CHECK CONSTRAINT [FK_dbo.AspNetUserClaims_dbo.AspNetUsers_UserId]
GO
ALTER TABLE [dbo].[AspNetUserLogins] WITH CHECK ADD CONSTRAINT [FK_dbo.AspNetUserLogins_dbo.AspNetUsers_UserId] FOREIGN KEY([UserId])
REFERENCES [dbo].[AspNetUsers] ([Id])
ON DELETE CASCADE
GO
ALTER TABLE [dbo].[AspNetUserLogins] CHECK CONSTRAINT [FK_dbo.AspNetUserLogins_dbo.AspNetUsers_UserId]
GO
ALTER TABLE [dbo].[AspNetUserRoles] WITH CHECK ADD CONSTRAINT [FK_dbo.AspNetUserRoles_dbo.AspNetRoles_RoleId] FOREIGN KEY([RoleId])
REFERENCES [dbo].[AspNetRoles] ([Id])
ON DELETE CASCADE
GO
ALTER TABLE [dbo].[AspNetUserRoles] CHECK CONSTRAINT [FK_dbo.AspNetUserRoles_dbo.AspNetRoles_RoleId]
GO
ALTER TABLE [dbo].[AspNetUserRoles] WITH CHECK ADD CONSTRAINT [FK_dbo.AspNetUserRoles_dbo.AspNetUsers_UserId] FOREIGN KEY([UserId])
REFERENCES [dbo].[AspNetUsers] ([Id])
ON DELETE CASCADE
GO
ALTER TABLE [dbo].[AspNetUserRoles] CHECK CONSTRAINT [FK_dbo.AspNetUserRoles_dbo.AspNetUsers_UserId]
GO
Avec DB First, la modification de la chaîne de connexion ne va pas forcer Identity 2.0 à créer des tables dans la base de données.
CORRECTION: J'avais initialement mes tables d'identité dans la base de données sous un schéma d'identité et lorsque j'ai enregistré de nouveaux utilisateurs à l'aide de la méthode ci-dessous, de nouvelles tables ont été écrites dans ma base de données sous le schéma dbo.
Vous devez d'abord créer un projet factice à l'aide de Code. Créez et exécutez le projet, accédez à l'application en cours d'exécution dans votre navigateur Web, enregistrez un utilisateur avec un e-mail et un mot de passe factices. Cela entraînera Entity FrameWork Code First (?) créez toutes les tables de base de données Identity 2.0 dans votre base de données fictive. Vous voudrez ensuite exporter les tables factices vers un script SQL et les importer dans votre base de données existante dans laquelle vous souhaitez les utiliser. Il doit y avoir 5 tables: AspNetUserRoles, AspNetRoles, AspNetUsers, AspNetUserClaims et AspNetUserLogins.
J'ai un modèle d'entité ADO.Net (fichier .edmx) pour mes principaux modèles de base de données et un autre .edmx pour les modèles d'identité (j'ai nommé IdentityDbEntities). C'est à ce moment-là que vous devriez changer la chaîne de connexion de "DefaultConnection":
public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
public ApplicationDbContext()
: base("IdentityDbEntitiesString", throwIfV1Schema: false)
{
}
TRÈS IMPORTANT: Dans votre fichier Web.config, vous devez ajouter une chaîne de connexion supplémentaire que vous utiliserez ci-dessus. On dirait que (j'utilise un environnement SQL Server Dev, vos chaînes de connexion pourraient donc changer):
<connectionStrings>
<add name="IdentityDbEntitiesString"
connectionString="Data Source=#MyServerAddress#;
Initial Catalog=#DbName#;
Integrated Security=SSPI;"
providerName="System.Data.SqlClient" />
<add name="IdentityDbEntities"
connectionString="metadata=res://*/Models.IdentityModel.csdl|
res://*/Models.IdentityModel.ssdl|
res://*/Models.IdentityModel.msl;
provider=System.Data.SqlClient;
provider connection string="
data source=#MyServerAddress#;
initial catalog=#DbName#;
integrated security=True;multipleactiveresultsets=True;
application name=EntityFramework""
providerName="System.Data.EntityClient" /> </connectionStrings>
Tout ce qui est à l'intérieur de # comme # DbName # sera personnalisé pour vous.