We have a DB2 database which is used by legacy applications that we are in the process of decommissioning and we have an Oracle database that we are developing new applications for. In order to maintain compatibility with legacy applications until they are completely decommissioned and keep data in sync, we are using Atomikos for two phase commits. This however is resulting in a lot of duplicated entities and repositories and thus technical debt, because the same entities and repositories cannot be used by the same entity managers so we have to duplicate them and put them under different packages for the entity scanning.
In most cases we want to read data from the legacy database and persist to both, but ideally this would be configurable.
Any help on this would be greatly appreciated.
Related
we have a big monolithic project that use EF to manipulates a database.
Now I want to start to create different services or micro-services that use a part of the big-model.
As first step read-only data may be good, but I have to reference all big-model or there is some different way ?
Any help are wellcome.
You can start with all the microservices sharing the same large DbContext, and maintaining the single shared database. This allows you to build new services without complicated refactoring of the existing application or database schema.
I have a concern that I would like some input on to see if there is a solution. We have an ecosystem of about 30 web applications that all connect to the same database. We are going to be updating the applications and with that we are going to be moving to a new database schema. I have a process that will be pulling all the old data into the new schema using EF Code-First for the new schema.
Well, today I ran into an issue when two branches of the solution that I wrote to migrate the data have a slightly different schema (one branch put a MaxLength on a field and an index on another). The issue that I had was that the database was out of sync in one branch, but up-to-date in the other and the branch that was out of sync would not run until I ran Update-Database.
I was thinking about putting the code-first poco classes into a library along with the DataContext to be able to be used by the various web apps. I would then make this library available to the team using an internal NuGet server.
My concern is that if the schema changes (doesn't happen very often, but it does happen) what happens to all of the web applications that are relying on this library for data connectivity? Would they all break (my assumption is that they would)? If so, all of the production web apps would be down. Is there a way to get around this?
We have recently begun using Entity Framework for accessing all the various databases we touch on a regular basis. We've established a collection of library projects, one for each of these. For many of them, we're accessing established databases that do not change, and using DB first works just great.
For some projects, though, we're developing evolving databases that are having new fields and tables added periodically. Because these libraries are used by multiple projects (at the moment, just two, but eventually many more), running a migration on the production database necessitates a republish of both/all sites that use that particular DB's library. Failure to update the library on any other site of course produces the error that the model backing the context has changed.
How can we effectively manage the deployment/update of the Code-First libraries to all of the sites that use them each time a change to the database is made?
A year later, here's what we came up with and have been using.
We now include the following line in the Application_Start() method:
Database.SetInitializer<EFLib.MyHousing.MyHousingMVCContext>(null);
This causes it not to throw a fit if the current database model doesn't exactly match what's in the code. While there is still potential for problems if non-backward-compatible changes are made, this allows for new functionality to be added without the need to re-deploy every site that uses these libraries when the affecting changes are not relevant to that particular site.
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 have developed a number of departmental client-server applications, and am now ready to begin working on moving one of these applications to a SaaS model. I have done some basic web development, but I'm a newbie when it comes to SaaS architectures.
One of the first questions that comes to mind as I try to design the architecture is the question of single vs. multi tenancy. The pros and cons of each vary significantly depending on the type of application and scale required, so I'd like to describe my application and scale needs below, and hope others can comment on how I should get started with the architecture.
The client-server application currently consists of a Firebird database and a Windows application. The database contains about 20 tables containing a few thousand records in 4 primary tables, and a few hundred records in various lookup and related tables. Although the number of records is small, the size can get large, as the database can contain large BLOBS. Each customer sets up their own database and has a handful of users within the organization connected to it. When I update the db schema, a new windows application is released, and it checks the db schema and then applies the updates as needed.
For the SaaS application, I am designing for 100's (not 1000's or millions) of new customers per year. My first thought was to go with a multi tenancy model to make updates easy (shut down apply the updates to one database, and then start up). On the other hand, a single tenancy model would provide a means to roll updates out to a group of customers at a time, and spread the risk of data corruption - i.e. if something goes wrong with a database, it will impact one customer instead of all customers. With this idea, I was thinking of having a single web front-end which would connect to a single customer database upon login. Thus, when a new customer creates an account, a new database would be created (each customer would have their own db with multiple users as needed for the customer).
In this model, a db update would require either a process to go through each db to apply schema changes, or a trigger upon logging in to initiate a schema update similar to the client-server model currently in use.
Can anyone point me to information for similar applications which have been ported from client-server to SaaS? Or provide any pointers to consider? Basically I'm looking for architecture examples of taking a departmental application and making it available as a self service website for multiple customers. Thanks for any suggestions, resources, etc.
Good questions.
One thing that comes to mind is that if you have multiple databases which you roll out in a staged manner to reduce the likelihood of breaking all of your customers, you will have to address the issue of what to do if the db structure changes. You will either have to be very rigorous with respect to maintaining backward compatibility, or else deploy separate versions of your code base and somehow manage which tenants are associated with which databases.
We are providing our application using a SaaS model as well.
It was, initially a Windows app which worked similar to your multiple database proposal. Upon login, the win app would authenticate against a single "licensee" database which would then respond with connection information for a database specific to that licensee. The nice thing about this was that it provided 1) physical separation of licensee data, which our customers liked and 2) enabled us to physically locate the database on a server geographically closer to the users which both improves performance and avoids some potentially tricky legal and regulatory issues with respect to providing data across country boundaries.
Of course, since the app was a thick client app, we could get away with making database changes and pushing them out to one licensee at a time. When we were ready to upgrade, we could push out an updated thick client in conjunction with the new database - thereby ensuring that the codebase was a match with the database. As long as the common "licensee" authentication database stayed consistent, this worked fairly well.
On the other hand, though, this solution brought with it all of the problems of maintaining and managing a thick client approach which finally lead us down the thing client, browser-based approach.
In our new model, everything is in a single database. When we have updates, we push both the code and the db out at the same time. This solves the problem of keeping the code base consistent with the database structure. However, we are now confronted with the issues mentioned in #s 1 and 2, above, which we have yet to resolve.
I hope this provides some food for thought for you.
I, too, am interested in this question.
Thanks for the post.
-S