I'm working on a database schema that involves two static sales agency that have the same database model.
For example:
dbo.User becomes
paris.User and toulouse.User
Our project works with Linq To SQL and we use sqlmetal to generate two map files one for the Paris agency and the other for Toulouse.
With active directory, we are able to detect where the user come from and by that, we choose the map file corresponding to his agency.
My question is:
Is there a way to do the same in Entity framework ?
if not, what can i do ? and what's the best solution that i should follow, while using Entity framework.
You can have multiple dbcontext in entity framework so depending on your agency you can use the different dbcontext.
Related
I have a SQL Server with multiple databases.
I'm trying to build a "database browser" with Entity Framework 6.4.4 (in C#, ASP.NET MVC 5) that allows users to access any data stored on a particular SQL Server.
The problem is that we already have a huge amount of databases each containing as many tables and columns and it would really be a pain being forced to generate a model for every database by hand.
Therefore, I thought the entity framework would provide a way to generate a sort of "ServerModel", making it easier to handle multiple databases but also have them packed in a single generated model.
I would use such a model like this:
ServerModel sm = new ServerModel("Sql server name");
//list all databases
foreach(var db in sm.Databases) {} // or maybe sm.ToList() ?
//access specific database model and table
sm.MyDatabase.MyTable.ToList()
I couldn't find anyone trying to achieve this with Entity Framework online.
Is Entity Framework made for this?
Or should I start thinking my own solution?
And... does anyone have any?
The company I work for is researching new possibilities for applications that we can develop, one of the things we would like to do, is be able to dynamically map tables in Entity Framework Core, or any other ORM if Entity Framework Core does not have this possibility.
Let's say we develop an application that we distribute to multiple customers, one of those customers mentioned that they want to have a new entity with certain fields, we update their database to include this model/table, but rather than updating the application to include this new model, is it possible in some way to have Entity Framework Core dynamically map this table?
So far I've searched around on google, but most of the questions I have found are about a model with a different table name, but having the same fields.
One solution could be to use dot net compiler platform (Roslyn) and then make a program to make the program.
I have an odd situation. I am working on a project with a very large existing database that is completely unrelated, but does contain corresponding table id's. It's as if someone copied the database but never related the tables.
In Entity Framework, is there a way to go EF code first and create the relationships in code, but Not apply those relationships in the database? I would like to go through and relate the database but the client doesn't want to pay to fix it.
Thanks!
In this instance, it seems you would be best to add relationships directly to your database (or to a duplicated database for testing/staging) and then just update your entities using your test connection and regression test your app.
Assumptions
Using EF 6.1, MVC 5, VS 2013, C#
I have an existing database model designed in Toad DM for SQL Server and it's very important keep it always updated
Steps and Notes
Using ADO.NET Entity Data Model I chose Code First from Database (new feature in EF 6.1) to generate the models. Note: Model classes and DbContext class generated successfuly but NO .edmx or .tt file was generated.
Next I added a new scaffold item: MVC 5 Controllers with views, using Entity Framework. Note: Success, controllers and views generated
Question
From now on I don't want to use Code First to update my database. Instead I want the models to be updated based on database changes. What to do next? If I don't have an edmx file will I not be able to update my model classes from the database?
The Entity Data Model Wizard's Code First from Database does an excellent job creating your entity classes, as if they were created in the Code First style. What you are asking is if there is any way to keep these classes up-to-date as your database changes, similar to the EDMX style "Update Model From Database". From what I've researched this is not possible using the built-in tooling. However, here is one workaround that I've found useful:
Let's say I have database with a product table and customer table. Originally I created a StoreDBContext class, and selected product as one of my objects. Now I want to add the customer table as a new entity to the existing context. Here's how to do this using the Code First Wizard:
Create a new Entity Data Model, call it StoreDBContextTemp or whatever
Choose the code first from database wizard option
Select customer as an object to add (just customer) & complete the wizard
Open the newly created context file, StoreDBContextTemp.cs, and copy the virtual properties of your newly added entities:
public virtual DbSet<Customer> Customers {get; set;}
Paste these new properties into your Original StoreDBContext.cs dbcontext class.
Delete StoreDBContextTemp.cs, and remove the connection string for StoreDBContextTemp in app.config/web.confg etc.
You can now use Customer on the StoreDBContext class
If you add or remove tables you will need to manually adjust fields, but at least you won't need to hand write dozens of properties each time a new table is added to the model.
One more option is just delete the auto generated classes from the project and once again generate them.
While following this approach only thing we need to make sure that is we should give the same name for the data model(class name which inherits from DbContext ) as the previous one.Data model name is highlighted in below snap
Three things.
There's no .edmx when you use Code First.
If you use Code First Migrations you would have to write first the code and after that migrate the changes to database. This helps you to have much more organized you code with no generated code which is an advantage.
There's a plugin in Visual Studio for doing contrary. Entity Framework PowerTools allows you to select the database and map it to objects.
https://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d
The best solution to me is deleting the model and recreate updated one with the same name, keeping in mind two points:
Personal extension methods implemented for the model;
Possible manual relationships between tables added to the model because of not setted up in the phisical db.
My personal solution:
Move all extension methods to another partial class that won't be overrided;
Insert all added properties of an entity to another partial class;
Keep track of all manual relationships in an help file, so you can add them again being sure not to loose anything;
Delete the old model and recreate one new with the same name and update it with the manual relationships of point 3.
I am developing ASP.NET (WebForms) app and using EntityFramework. I was wondering what is the best practice of using entities. Create few entities for whole database or create many entities for specialized purposes ?!
Example case is this:
I have customers table. This table have ForeignKey to customers_addresses and customers_phones tables. I got two cases on this dataset
Autocomplete customer name
Show user details
For case 1 I got one entity which have only the "name" column mapped to user to db
For case 2 I got another entity which have all data and connections between other tables.
Now I was wondering if only single entity (number 2) would be good for both cases.
What's the best practice with EF ?
I don't see a reason, in your case, to have a specialized entity for the autocomplete scenario. Since you'll be using Linq to Entities for all your querying, just make sure you are selecting just the Customer Name from the entity, instead of the entire entity itself
from Customer cust in ent.Customers
select new {
CustomerName = cust.CustomerName
};
That way you still have lightweight SQL query on the backend, but you're not polluting your models with unnecessary, "specialized" entities.
In addition, if you're using lazy loading then you don't have to worry about EF loading any related entity information unless you actually need it.