So the problem is: I am working with a legacy project. Creating a web interface to databases. ASP.NET Core, CRUD, that usual stuff. BUT!
There are 3(three) databases. Let's say there are Companies and Employees tables in each one of them. And there are Companies in the first database which employees may be found in first, second and third databases.
Currently, I am writing custom queries to target multiple databases. Working directly with MySqlConnection classes and MySqlDataReader.
It gets the job done, but I am really missing Entity Framework's lazy loading
I know I can create multiple EF contexts, one for each database, but it's not gonna work because as I said - data may be spread out through all 3 DB.
Is there any better way to communicate with multiple databases?
You can create synonyms in one database for tables located in another database and try to use it in EF.
Related
I’m working on a project with over 15 databases, I need always to join tables from different entities so I end up using .ToList.
I had an advice from a friend to do a database link-server and then to create views in the same database for all the references tables.
But I'm not happy with both of them.
Is there any alternative solution other than .ToList & database views and what is the best practice in this case?
Plenty of ways around this, each with their own disadvantages.
Linked databases with views
Check the usage on the Microsoft docs
The ability to access data from outside of SQL Server.
The ability to issue distributed queries, updates, commands, and transactions on heterogeneous data sources across the enterprise.
The ability to address diverse data sources similarly.
Point three is your case exactly. You also have the ability to link multiple databases like mysql if need be.
A lot of disadvantages though (check here). I will add one of my own and say that
Implement with code and automapper
If all the tables are similar, then you can use a tool like automapper to make easy lists from your data
Get your data with entity framework
Map to DTO objects with the common properties using automapper
Merge your lists with Range add.
Duplicate data
We live in a world were nosql solutions are used alongside RDBMS solutions. it might be that you create a common db (RDBMS or nosql or whatevers suits you), and duplicate your data there.
It's extra work but it's the fastest in usage.
I could think of more, but this is the gist of it.
I am working with EF6, MSSQL, Oracle, .NET4.5 on a system that is used globally across company (many departments) to query different databases that belong to our department, that have mostly same EF model, some databases are Oracle and some are Microsoft SQL, some are development or uat, some are logs.
I am using different EF models for Oracle and for MSSQL databases.
One requirement is to switch between databases at run time, and this is easy,
public AggregatorEntities(string connectionString)
: base(connectionString)
{
}
however it does have side effects - many databases (dev, uat, dr, logs,...) are out of sync from what Live is (model is generated from Live), which results in errors when querying those databases.
Management knows about situation and they are ok for devs that work on some specific database to do changes to global querying system that would allow testers and uat to query the data. However they want changes they have to do to take minimum time to do this - as it is additional cost to each project that involves database changes. I will basically need to build a 'can handle all' resilient system, that when one changes database in EF will do something to accommodate to specific database.
There are different failure scenarios:
1. Name of column on table is the same but Type is different in entity
2. No column on table but there is one on entity in EF
3. Additional columns on table that are not on EF
4. Additional tables in database that are not in EF model
5. No table in database but there is entity in EF model.
I have done some thinking and this question is broad and might get closed for same reason. However I am not sure if it is worth splitting the question into each scenario, as it depends on the answer. The way I understand if single answer can answer all points then no need to split, however if each situation has different 'cure' then question should be split for that part only, but without answer no way to know.... (catch 22).
Only option I see ATM is to generate it's own model for each mirroring database, but then I end up with 50+ models.
How do I allow EF to work with different database structures at run-time?
This now officially cannot be done in a proper manner.
However end result of being able to switch between different databases with similar structures still can be achieved (for those without morals). Part with removing columns can used.
Solution is to have all inclusive EF model that is generated from database that has all the tables and all the columns (that are in any database think like logical OR of everything). Then model with all entities that have all properties from all db environments can be removed specific to environment that is queried at runtime in mechanism described here. This does not cover cases where type of column changes.
Hope this saves you some time as it took 2 weeks from mine...
I have an MSSQL DB with more than 1000 tables, and I wanted to use EF 6 in my project as DB is large and already running with another system so I will go with DB first approach.
My question is that what is the best practice to use multiple EF data models(each will contain 10 or less tables) will communicate with each other as it will be in different context (e.g. getting data from product table in sales model).
How to manage same Tables in different models e.g. users table probably will be in each model.
Is there anyway that I can use for updating all models at once or is there any post-build option to automate updating all models from db and what will be the affect on customized tables.
Already done: Created multiple data models in the same project with the same DB in different folders(working fine).
Thanks.
The answer to all of your questions is Domain Driven Design.
Go through Julie Lerman's DDD Bounded Context. She has explained everything in an obvious and comprehensive way.
For data sharing she has another article. Have a look at this too
I would like to add new module (project) to my solution and to use entity framework code first only for subest of my database tables. I'm using ADO.NET with stored procedures in other modules. I plan to split tables from db in the future, but for now it is not possible (tables have no relations to other tables but are used by old modules) I'm not sure if it is good practise to do it in this way and I would like to ask for help.
is it possible to use EF code first for subset of the tables of my DB?
how to initialize these tables with code first? I found only solutions to drop whole
db if model doesn't match and recreate new DB. I need drop and recreate only
tables that are used in my project
is it good practise to use more approaches of the db access to one db?
do you see some problems in this approach? Now I see problem with concurency and data consistency ( if old module will operate with this tables in another approach )
Thank you.
1) Yes, it is. On one of our projects, we had database with store procedures which we migrated to use EF. But not at once. It had taken some time so we used Store procedures whit ADO.NET as well as EF together.
2) I must say I'm not sure about this. We had database already created with only few changes. But you could created tables by yourself.
3) I think better would be to call stored procedures from EF and use it on whole projects if you need them. But using both, ADO.NET and EF is ok, if you have reasons.
4) Why it would be problem if you will use transactions?
My situation is as follows. I'm using entity framework (4.0) in which I have defined a relatively simple model like, let's say, two entities:
user
transaction
A user can have multiple transactions in this scenario. When generating the database this would result (obviously) in 2 database tables names 'user' and 'transaction'.
The problem is that I want to use the code as a webservice where different companies should have their own environment (read: own users and transactions). A simple solution would be to add a column to both tables like, lets say 'company_id' to identify one user/transactions for companya from the user/transaction from companyb.
What I would like to have is a duplication of the tables like so:
compa_user
compa_transaction
compb_user
compb_transaction
This way..all data would be nicely separated and if company a generates a lot of transactions, company b would not notice that the system is getting slow or whatsoever.
My question: is there a way to accomplish this based on entity framework. So, can I have multiple tables representing one entity in my model and switch from table to table depending on which company is connecting to the service.
Any help appreciated!
If you really want to keep the tables seperate, then a seperate database for each client would be the easiest - only need to change the connection string in EF.
The other benefit of this model (seperate databases) is that the database will scale quite easily as each database could theoretically be on a different database server should the DB ever become the bottleneck.