Ihave a DB First EF5 project that I am implementing SimpleMembership in. I have most of it working, but a question has come up.
The main User table created by Simple Membership has the UserName in it. I have a couple other places in the app where I need to query this table, specifically the userName. Simple Membership does not use the Data.EntityClient in the connection string, so i have it set to the SqlClient.
So because i don't have an entity model with the provider User table, I am not sure how to query it. Usually i would create an instance of the entity model and use LINQ on it, but when I try it I get a very long winded error about mixing code first with entity first. I have modified the 'initialSimpleMembershipAttribute' so it points to the separate connection string I made for the Membership tables.
One solution i thought of was to save the user, then copy the username to one of my custom tables, then i can query it through EF, but this seems like it would violate some kind database 'best practice' of duplicated data.
Another idea I had is to create a second edmx model for the tables that Membership created, but if SimpleMembership does not use the EntityClient, does that also mean it will not recognize a entity model?
You're way over complicating things.
If you have your own model, then you can just get rid of the model that the default template gives you, and use yours instead. It doesn't matter if it's Code first or database first or whatever. Just change the Initialize SimpleMembershipAttribute to remove the references to the default model they give you, and make sure you modify the InitializeDatabaseConnection call correctly.
WebSecurity.InitializeDatabaseConnection("YourConnection", "WhateverYouCallYourUserTable",
"WhateverYourUserIdIs", "WhateverYourUserNameColumnIs", autoCreateTables: true);
Related
I'm using Identity 3 and I want to add some columns in AspNetUser table.
I've tried to do it using EF Core Code first and it's working well but I need to do it DB first.
I was wondering, if I will create the columns manually in database, then create the ApplicationUser class with corresponding properties, will it work?
Yup that should work, I've done it before.
However as time goes on I ended up having to add so many that it got messy.
So eventually I refactored those extra columns into their own related tables:
e.g: User_AdditionalDetails
This was a massive pain as I had live users and had to write scripts to migrate everyone's data etc.
This way you would only need to add a single FK for the related table with all this extra info.
It also neatens the code too, and gives the benefit of being able to load different sets of user properties only when they are needed.
If it's for an application scope property of the user like 'Region' which determines behaviour of core functionality of your app, then I'd say add it straight onto the main ApplicationUser class.
My entire group is new to ASP.Net Core and I was the lucky one tasked with Authentication/Authorization. We have always used a DB first approach, and this is no different, we already have our DB all set up. The higher ups want to use our specific tables for all things Identity, but they also want to leverage the tools that ASP.Net Core gives.
This will be a multi-site app where there is one central database. Our current setup is close to what the scaffolding adds, but has some small differences.
I have read a ton of resources, but the vast majority all focus on the code first approach and I currently don't fully understand what I need and what is there for the code first approach. I have seen a couple of answers that recommend using the .ToTable and .Property inside of OnModelCreate. Is this the best option or am I better off creating my own stores and methods? I currently have a user model created and a store to go with it (based on this site). Is it best for me to try to expand that all the way out (don't full understand how to have it pull in roles and claims).
This is what our DB Schema currently looks like.
At this point we are creating our Roles and Claims via a db script. The only thing we will be using UI's for right now is a page that will let a site admin add users, and assign them roles, and any singular claims they need.
Any help or input would be greatly appreciated as I try to wrap my head around all of this. If I have left out any pertinent information please let me know. As I said with what I have now I can create a user and login, I just have no idea where to go from here (how to add roles and claims).
Here's how I think about it and the steps I would take to approach in solving this problem.
So Microsoft's implementation of Identity is an abstraction of the problem.
The Models that they provide and the Tables that are derived from them is their choice for the default implementation of the abstraction.
So essentially what you want to do is to plug in your models in to this abstraction.
To quickly generate these models from your database you might want to use scaffolding this will generate the DbContext and the Models, you will then have to configure the dbcontext to plug in your design.
And if you look at how you can create your own Identity Tables providing your own objects
here this can give you an idea of how to plug in your models/functions in to this abstraction.
You will most likely have to override the OnModelCreating method to configure the relationship of your tables.
I know that each time a user registers in my ASP.NET MVC application the ApplicationUser class is used to create the new record and put it in the database.
I was wondering if it's okay to add properties to that class for example I want the model to have a column in the database for DateOfBirth. Then use that class(model) directly in my application when I have to do some business logic things, database queries and similar stuff. Or is it more correct to create a new table in the database called let's say ApplicationAccounts, that saves the general info about the account. Each ApplicationAccount will be associated with a ApplicationUser(1 to 1 relation) and be somewhat of a buffer in the communication with the real accounts. Does that make sense?
I would go with the second option : create your own table, link them up in a one to one relationship using the UserID as a unique foreign key and then go from there.
One note here, it is perfectly normal for the model you need for the views to be different from the database model, this is because your db model can hold a lot of data that your view doesn't actually need. You might want to consider having separate models and use something like Automapper for a quick translation from one to another.
In my code I am trying to check if my entity framework Code First model and Sql Azure database are in sync by using the "mycontext.Database.CompatibleWithModel(true)". However when there is an incompatibility this line falls over with the following exception.
"The model backing the 'MyContext' context has changed since the database was created. Either manually delete/update the database, or call Database.SetInitializer with an IDatabaseInitializer instance. For example, the DropCreateDatabaseIfModelChanges strategy will automatically delete and recreate the database, and optionally seed it with new data."
This seems to defeat the purpose of the check as the very check itself is falling over as a result of the incompatibility.
For various reasons I don't want to use the Database.SetInitializer approach.
Any suggestions?
Is this a particular Sql Azure problem?
Thanks
Martin
Please check out the ScottGu blog below:
http://weblogs.asp.net/scottgu/archive/2010/08/03/using-ef-code-first-with-an-existing-database.aspx
Here is what is going on and what to do about it:
When a model is first created, we run a DatabaseInitializer to do things like create the database if it's not there or add seed data. The default DatabaseInitializer tries to compare the database schema needed to use the model with a hash of the schema stored in an EdmMetadata table that is created with a database (when Code First is the one creating the database). Existing databases won’t have the EdmMetadata table and so won’t have the hash…and the implementation today will throw if that table is missing. We'll work on changing this behavior before we ship the fial version since it is the default. Until then, existing databases do not generally need any database initializer so it can be turned off for your context type by calling:
Database.SetInitializer<Production>(null);
Using above code you are no recreating the database instead using the existing one so I don't think using Database.SetInitializer is a concern unless you have some serious thoughts about using it.
More info: Entity Framework Code Only error: the model backing the context has changed since the database was created
I have a SQL view to integrate with my application. I have been using Entity Framework till now. But the problem is that when I add a view to Entity Framework it starts treating my view as a table.
What I really want to know is, am I missing on something? Also if I use Nhibernate will this problem be resolved? Will it treat the view as a view only?
This view is a very complex query which has multiple joins and aggregation. That is why I am using a view.
But the problem is that when I add a view to Entity Framework it
starts treating my view as a table.
No it doesn't. If you add view to your model through wizard (EDMX designer) it will internally handle the view as a defining query which makes readonly entity. At entity level (the conceptual model) you don't see a difference because it is just another entity / class but if you try to make changes to instance of that class and save them you will get an exception (unless you map stored procedures or custom SQL commands to insert, update and delete operations for that entity).
Edit:
Database views as well as other database specific features like stored procedures or SQL functions are only for database first scenario (when you are using Update model from database in the designer).
Using Generate database from model is for Model first scenario where you tell VS: "Here is my model and I want some database to store it." First of all only information from conceptual model is used (original mapping and database description is replaced with a new one every time you run this command so even mapping to original database can be broken). It cannot create database specific features for you because it doesn't know that class should be mapped to view and moreover it doesn't know how should the view be created (the query from original view is unknown).
You can force VS to create the view for you but it is a lot of work in T4 templates where you will have to somehow provide SQL creation script for the view.