I currently have an n-tier application using entity framework 4.0 and we're looking at synching the contents of database between redundant servers. Does anyone have any experience on tips on how best to approach a solution?
From an architecture point of view, you need to consider if you want to do this at the application level or the database level.
At the application level you could write to both databases any time you made a change.
At the database level you could use the replication tools build into the database that you use.
You could also use a 3rd party tool. There is also a sync framework available from Microsoft.
Related
My company's main software application hasn't been updated in twenty years. I expect to soon be working on a complete rewrite of it. To that end, I am beginning to work my way through the book "Pro ASP.Net Core 3" by Adam Freeman (8th edition).
Our application was written to be independent of specific database types. Most of our customers use PostgreSQL, but a few use SQL Server. Therefore, we use ODBC because ODBC drivers exist for both of those databases, as well as several others. The application does not do anything fancy with the databases, and ODBC works well. We configure an ODBC DSN to talk to whichever database the customer has, and the application itself doesn't have to be changed.
A search on "Entity Framework Core ODBC" led me to the EF Core Github, where people have asked similar questions, and the answers were mostly along the lines of "why on earth would you want to do that?". Well, I need to do that.
Can I use EF Core with ODBC, or is there some other way that I can set up an Entity Framework Core application that does not have to be modified if the underlying database changes from PostgreSQL to SQL Server?
You could use your appsettings.json to store a value used to swap between the two. Those environment configs get reloaded on change (though you might have to restart your application to read them again, I'm not sure on that one).
Regardless something along the lines of this would suit your needs I think.
if (Configuration.GetSection("dbOptions")["postgres"]))
services.AddDbContext<ApplicationDbContext>(options => options.UseNpgsql(Configuration.GetConnectionString("PostgresConnectionString")));
else
services.AddDbContext<ApplicationDbContext>(options => options.UseSqlServer(Configuration.GetConnectionString("SqlServerConnectionString")));
EDIT: I placed this in Startup.cs where you would normally configure the DBContext. I use a similar solution reading off the Environment type to load either the Prod or QA connection strings based on deployment. In principle, this should accomplish the same task without the need for rebuilding and redeploying the code base.
So, I've read repeatedly that EF Core will support NoSQL databases but I can't seem to find any "official" NoSQL database providers, or even a NoSQL framework in the source code. (By "find" I mean search for "nosql".)
I've had a quick look at ADO.NET (paid) and crhairr/EntityFrameworkCore.MongoDb but they are both third-party. MongoDB (the specific database I was looking into) has their own .NET driver but it doesn't seem to integrate EF Core.
Anyway, what I really want to know is:
Does/will EF Core support NoSQL databases? What does "support" entail?
Does/will the MongoDB .NET driver support EF Core?
The results of my research so far seem to indicate that I'm misunderstanding something and it would be great if anyone could point it out.
Currently, the 2.1 EF Core roadmap doesn't show any new providers for NoSQL DBs.
(https://learn.microsoft.com/en-us/ef/core/what-is-new/roadmap)
Yet, they are now focused for Azure Cosmos, which is a cloud DB service. In Cosmos, you can use MongoDB API. More info about the progress (https://github.com/aspnet/EntityFrameworkCore/issues/8443) and Cosmos & MongoDB(
https://learn.microsoft.com/en-us/azure/cosmos-db/create-mongodb-dotnet)
For non third party MongoDB provider, it will take some time. You must understand, that .NET Core is a huge change from .NET Framework, because it now embodies the open source culture. Many libraries and tools are available and will be available without "Made by Microsoft" stamp. It's up for the community to create libraries and tools for .NET Core.
There is an open issue on MongoDB's site about providing an officially supported EF Core provider. If this is something important to you, you can vote for it there. (note, you must sign up for an account on their site to vote)
https://jira.mongodb.org/browse/CSHARP-3837
Update:
3/31/2022 - Status was changed to Backlog
4/28/2022 - Status was changed to Needs Scope, Quarter set to
FY23Q2
6/22/2022 - Status was changed to Scoping
7/29/2022 - Quarter set to FY23Q3
1/20/2023 - Status was chagned to Backlog
We have a couple of large, mature apps installed in hundreds of medical clinics. These apps are built using Windows Forms and WPF and although we host the database for some of them, the majority of our clients have a local install of the database.
We are in the planning stages of rebuilding our application on the ASP.NET MVC platform using Entity Framework. We will also be re-architecting our database, but for reference, the current database has about 600 tables and 1900 stored procedures. Although we don't have an official DBA, we have enough DBA skills to build and maintain what we have, so we are capable of designing and building the data model ourselves. Also, we will continue to have both on-premise and hosted solutions.
Our struggle is with deciding how to use EF. We're all in agreement that we should use code-first, but some of us think we should build our classes, decorate them with attributes, and allow EF to generate the database for us. Others think we should design and build the database and then generate code-first POCOs.
Assuming we will have non-CRUD stored procs, triggers, views, stored procs, and user defined functions, is database generation a reasonable approach? Are there reasons why it might be the preferred approach? Any good reasons for avoiding it altogether?
I would like to use a database in local application. During my research I found that SQLite and SCL Ce are the most appropriate for what I am trying to do. The most promoted ORM lately is Entity Framework 4 which unfortunately doesn't support these databases out of the box for desktop applications. What I am trying to achieve is to create database programmatically which ideally would be generated via "code first" or "model first" approach which later can be be manipulated via (CRUD) transaction. Should I go for Ling to SQL or maybe no ORM at all for better support?
Entity Framework 4.1 (Code First) fully supports SQL Server CE 4. Both are available easily via NuGet.
Im new to Microsoft entity framework and wonders if it's possible to use this framework with a DB2 iSeries AS/400? Are there any problems at all when working with this kind of "legacy systems"? and the EF framework?
You can use Entity Framework to connect to an ISeries DB2 database one of three ways:
1. If you purchase the license to IBM's DB2 Connect product. The license is around $12,000 which is outrageous. Also, there is not enough good documentation for how the DB2 Connect product actually works, how it installs, or its possible benefits. I've contacted one of their resellers to get a test install and it was not an intuitive process so we never purchased the product. Likewise, there doesn't appear to be any demos. I don't understand how IBM can have one of the best servers available but don't bend over backwards to leverage their product to Microsoft developers.
That said, if you research this topic you will find much information saying that you can use Entity Framework using their ADO.Net data server provider. I went down this path but I will warn you that their data server provider only works when DB2 connect is installed. This is confusing because IBM advertises this ability but doesn't often show the direct correlation between the two products so you're often left thinking that it will work without db2 connect which it will not at this time.
2. Purchase a third party data provider designed for Entity Framework. Progress software's Data Direct is super easy to use. I don't like how their server licensing works though because their server license is per core processor for your app server. This is flawed because this assumes you only have one app server when in reality, people regularly need to have different app servers for load balancing. I would prefer they just license per one ISeries server. However, you can purchase the licenses for each individual user if you decide to do that.
3. Write your own data provider. This is possible but there are obvious drawbacks.
It sort of looks like it is - see here:
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.swg.im.dbclient.adonet.doc/doc/c0054118.html?resultof=%22%65%6e%74%69%74%79%22%20%22%65%6e%74%69%74%69%22%20%22%66%72%61%6d%65%77%6f%72%6b%22%20
but quite honestly, I'm not 100% sure - especially not if it supports EF 4.0 (yet).
Or check out the IBM DB2Connect site and search from there...