LightSwitch Data Freedom – Part 4

This article is part of a series of posts from Xpert360 Development Team to address real world scenarios and problems faced when designing, creating and implementing Visual Studio LightSwitch applications.

Intrinsic, or not Intrinsic, that is the question!

…or at least it has been since LightSwitch launched. Do you connect to an external data source or use an intrinsic database?

On the one-hand, designing your database in LightSwitch is quick and convenient, LightSwitch looks after the database upgrades on deployment.

On the other hand, more fully featured database support, perhaps by design, perhaps to support other systems, perhaps for corporate policy.

We certainly like doing database design in LightSwitch for mock-ups, proof-of-concept or prototype applications. If business and technical requirements allow, that may be the end of the intrinsic/external discussion.

With Visual Studio 2013 Preview, LightSwitch projects now come with a database project option. This will change the balance of the decision criteria for the intrinsic/external debate. True, you could achieve similar before but it was more manual and time-consuming. See:

o – Intrinsic Database Management with Database Projects (Chris Rummel)

o – MSDN: Managing the Intrinsic Database for LightSwitch

o – Adding Stored Procs to your LightSwitch Intrinsic Database

This is a good step forward and extends the continued use of the Intrinsic database to more scenarios. But what if this is still not enough? Can you have the convenience of an Intrinsic database for the earlier part of a project and switch to external data source later.

In reality, standard LightSwitch is not going to handle this well. You are almost better off rebuilding your project from scratch, as that is what LightSwitch will force you to do. If you do this at the end of an early prototype project or proof-of-concept stage, it may be an unwanted be achievable step.

An alternative is to stick to using an Intrinsic database and manually reapplying schema changes to it to match any schema changes in the external database. If managed properly, it is a workable solution. Then you stop using LightSwitch to push schema changes out during application deployment.

We have tried two different paths that can delay moving to an external database to much later in a project’s cycle. The main point is to avoid any potentially large volume of rework to make the process quick and safe, if you choose to do so.

Another scenario not covered is in this forum post:

o – MSDN Forum: External Database vs Intrinsic Database

In there is a frequent need to run the LightSwitch application in Visual Studio debug mode against a multi-gigabyte copy of a production database. The logistics of data transfers mean that it is not feasible to move the data into the default intrinsic database. You just want to point the LightSwitch project at the existing restored database instance for debugging.

Path #1 – Export/Import facility to transfer assets between LightSwitch projects

Path #2 – Modify the project LSML to convert the Intrinsic data source to external

The second path sounds scary, and the first path sounds scary but is a bit more palatable. You will be trying this on backup copies of your systems first, right? In reality both techniques are of use in real world scenarios.

Conclusion

That sets the scene for manipulating the data source type in the next blog posts in this series…

NEXT UP:

LightSwitch Data Freedom – Part 5: Intrinsic, or not Intrinsic, that is was the question!

PREVIOUSLY:

LightSwitch Data Freedom – Part 1: The chains of legacy databases

LightSwitch Data Freedom – Part 2: Walkthrough shaping your data

LightSwitch Data Freedom – Part 3: Pre-filter the data