locked
Adding a new Context RRS feed

  • Question

  • User438705957 posted

    I have a website Portal where there is one SPA application that I built in VS 2017 EF 6.0 Code First, Web API etc with a HTML/JavaScript front-end. 

    I plan to add another independent application to the portal that will use the same VS project but points to a completely different database, albeit on the same server.

    I plan to create a new ADO.NET Entity Data Model(Code First from Existing Database) and DbContext that points to the new application's database.
    This is an existing database that is also used by an old Web Forms application I support, in a completely different website/server and VS solution.

    I suddenly realized that any design changes I make on SQL Server to the existing database, inline with the Web Forms website requests, will cause trouble with Code First migrations, as it will detect changes not inline with the known CF Migrations schema. 
    This could turn into a nightmare to support.

    Any ideas to get around this.

    Thanks for considering

     

    Monday, May 4, 2020 11:58 PM

Answers

  • User-1330468790 posted

    Hi Madog,

      

    I discussed this problem with some other developers and felt that it would be unsafe to have this design.

    Although you could avoid to delete the columns and keep the database being capable of running by communication between two different teams/developers, it requires a higher cost on cooperation and testing.

     

    If the two applications are completely independent of one another in the same database, it won't be a problem since EF6 migrations supports migration of multiple models in this condition. 

    If you check the __MigrationHistory table in the Code First database, you will find that there is a column called "ContextKey" which is used to identify the Migration from different context. 

    More details, you could refer to this: EF6 Code First Migrations for Multiple Models

     

    If the two applications are going to share one or more than one tables, you should be aware of troubles of schema difference

    I suggest you only allow the original application to be able to change the schema and DbContext of the existing database and then expose some data api for another application. That way, the new application is only allowed to access the data in the same database. If the new application has needs to modify the schema/DbContext, the new application's team should communicate with the original application's team, which will reduce the communication cost compared to the current design.  

     

    If you will have more applications facing the same problem, you might need to consider create a webapi project for data accessing, which would isolate the data access from other applications.

       

    Hope this can help you.

    Best regards,

    Sean

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, May 5, 2020 8:25 AM

All replies

  • User-1330468790 posted

    Hi Madog,

      

    I discussed this problem with some other developers and felt that it would be unsafe to have this design.

    Although you could avoid to delete the columns and keep the database being capable of running by communication between two different teams/developers, it requires a higher cost on cooperation and testing.

     

    If the two applications are completely independent of one another in the same database, it won't be a problem since EF6 migrations supports migration of multiple models in this condition. 

    If you check the __MigrationHistory table in the Code First database, you will find that there is a column called "ContextKey" which is used to identify the Migration from different context. 

    More details, you could refer to this: EF6 Code First Migrations for Multiple Models

     

    If the two applications are going to share one or more than one tables, you should be aware of troubles of schema difference

    I suggest you only allow the original application to be able to change the schema and DbContext of the existing database and then expose some data api for another application. That way, the new application is only allowed to access the data in the same database. If the new application has needs to modify the schema/DbContext, the new application's team should communicate with the original application's team, which will reduce the communication cost compared to the current design.  

     

    If you will have more applications facing the same problem, you might need to consider create a webapi project for data accessing, which would isolate the data access from other applications.

       

    Hope this can help you.

    Best regards,

    Sean

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, May 5, 2020 8:25 AM
  • User1120430333 posted

    Any ideas to get around this.

    Maybe, you need to stop doing migrations. EF or any ORM is not a DBA tool traditionally anyway. 

    Tuesday, May 5, 2020 1:10 PM
  • User438705957 posted

    Thankyou Sean Fang for taking the time to so thoroughly consider the issue.

    I am in fact the programmer supporting both these projects, so communication between teams is not a problem, as I quite often talk to myself.

    The old application is a Webform's app with no concept of DbContext etc.
    If I make a change to a shared table thru ADO.Net datasets in the Webforms app,  I will indeed run into issues with the Code First migrations in the new app.

    In any case, I have decided to bail on the whole idea of sharing tables and databases. The whole concept adds unnecessary complexity and is not simple to maintain and keep in synch.

    I will read the article you suggested as every bit of information helps in unravelling the mystery of EF and Migrations.

    Thanks again

    Madog

    Wednesday, May 6, 2020 11:42 PM
  • User438705957 posted

    DA924,

    I'm hearing you. Every time I make a change to the model, I just pray migrations gets it right when promoting to Production, especially since there is 'magic' involved that I can't control. So far, it's worked out.

    Cheers

    Wednesday, May 6, 2020 11:45 PM