One Model or Two? - Database First EF 6.0 to SQL Server (2005/2008) needs offline support to SQL Server CE 4.0

Question

I'm re-writing an old VB6 application which used SQL Server 2005 and Access MDB in VS 2013 C# with EF 6.0 to SQL Server 2008 R2 and SQL Server CE 4.0. The app has to function offline in the event of network errors, of which there are many. The offline version needs read-only access. Re-use of code was easy in VB6 I just changed the connections.

I have completed 98% of the code using a Database First model EF 6.0 (just upgraded). Now I need to add support for offline. I thought I could swap out the connections but have read-up that I can not. I'm open to changing the model used but would prefer to keep Database or Model First approach.

I have an external app that creates & copies all the data necessary from SQL Server to SQL Server CE and I have no need for SQL Server technology in the offline. I don't want to re-write all my code just to support offline connections.

I'm willing to support multiple EDMX models, one for SQL Server and one for SQL Server CE but before I do I wanted to get some opinions & advice.

In theory, the application will test access to the server at start up and connect to the offline if the server is not available (assuming the offline SQL Server CE is already generated and ready).

Answer 1

I am assuming SSCE means SQL Server CE. EF does support multiple back-ends for the same model. In this scenario you would have one CSDL and two SSDL and two MSL files. CSDL represents your model while SSDL represents your database (and is database specific - eg uses database specific database types). MSL is just telling EF how CSDL is mapped to SSDL. However the designer does not support this scenario since the designer work just with EDMX files and not separate CSDL/MSL/SSDL artifacts. You potentially could have two EDMX files but then you would have to make sure that CSDL is in both cases the same and you would have to disable generating code from one of the EDMX files - otherwise you would end up having two sets of entities which would create the conflict. Even though this could work there is a bigger problem - Visual Studio 2013 does not support Sql Server CE anymore. It means that there is no DDEX provider for Sql Server CE for VS2013 which makes it impossible to create/update EF models that use Sql Server CE since the EF designer relies on DDEX provider ( this is what happens if you try to use Sql Server CE with EF Designer on VS2013). Because of the above you actually might be better of trying CodeFirst approach. You would not need to worry about CSDL/MSL/SSDL since they should be built from your code (if you need to tweak the model in the way it touches store (eg you want to map to a column of specific store type) you would still have to have an if and tweak the model depending on the back end you are using but it should be much more manageable than separate SSDLs). CodeFirst does not depend on DDEX so again you could use it in VS2013 just by adding NuGet packages.