This article aims to explain tips and tricks for more in-depth development of your Turnkey application.
Turnkey architecture
The Turnkey AngularJS architecture has 4 physical tiers:
- The turnkey JavaScript-application that the user interacts with – this resides on the client – in a browser – or in an app
- The turnkey web-application – built with ASP.NET MVC – able to stream viewmodel transformed changes to and from the javascript application
- The MDriven Server that the turnkey web-application communicates with
- The database that stores your data
Responsibilities
Layer 1 has only access to information according to your designed ViewModels – any actual action is sent to layer 2 for processing. Layer1 allows for displaying and updating of viewmodel properties. Updates will be packaged and sent to Layer 2. Layer1 periodically asks Layer2 for updates since last time – Layer1 merges the diff-gram response with the local viewmodel representation. Changes from such merge will trigger subscriptions in AngualarJS display framework and UI will be refreshed according to AngularJS rules.
Layer 2 is responsible for transforming business objects to viewmodels, subscribe to changes and make available the changes as diff-grams. Layer 2 executes any logic on your business objects. Layer 2 upholds information security by controlling a per user access. Layer 2 is the traditional MDriven application level – it maintains a per user state area with the currently accessed viewmodels and a list of changes per such viewmodel. It uses lazy loading techniques for pulling data from Layer 3 as needed – and it also use look ahead data load techniques based on specification of viewmodels to dramatically improve load efficiency and reduce database round trips. Layer 2 also handle local changed state and owns the transaction context with commit and rollback of save operations.
Layer 2 upholds an undo and redo queue for all unsaved changes.
Layer 3 is responsible for OR-mapping – retrieving and storing business objects in the database. Here we can also do Server side jobs like sending emails, produce exports or imports that should execute periodically in your system. Layer 3 also manages client synchronization so that multiple clients efficiently see updates done by others without the need for total refresh of business object cache.
Layer 4 is responsible for persistence services as storage and efficient search with sql.
Data roundtrip
Layer 1 initiate all communication with Layer2. Communication is done over WebApi https rest interface – using JQuery Ajax calls –upload of datachanges are done by posting json data (https).
Layer 2 use the MDriven Datablock definition to send and retrieve data from Layer3 with WCF over Https.
Layer 3 talks to layer 4 using the appropriate ADO driver for the given database.
Semi-local for development
When you have access to Visual Studio you can develop your site locally in order to speed up the iteration loop. A common scenario is that you want to work with Javascript or Typescript on the provisioned data that Turnkey delivers.
The recommended and easiest way is to keep the server in the cloud (layers 3 & 4) – but have the turnkey application locally (layers 1 & 2). This is how that is done:
In the TurnkeyWebAppGeneric/App_Data directory add a fileApp_Data/MDrivenServerOverride.xml with content as follows:
<?xml version="1.0" encoding="utf-8"?> <root> <MDrivenServerOverride>https://[YOUR_TURNKEY_APP].azurewebsites.net/__MDrivenServer</MDrivenServerOverride> </root>
Doing so will let you execute the Turnkey app locally – but using the persistence mapper from the server.
You need also add credentials for your local Turnkey instance to access the server. by adding another file App_Data/TurnkeySettings.xml with content like this:
<?xml version="1.0" encoding="utf-8"?> <root> <ApplicationName>The Name Of the Turnkey app (shows in browser title)</ApplicationName> <MDrivenServerUser>a</MDrivenServerUser><!--this is always "a"—>
<MDrivenServerPWD>pwd as found in LicenseAndTicket</MDrivenServerPWD> <MicrosoftAuthentication_ClientId>As found in license and ticket</MicrosoftAuthentication_ClientId> <MicrosoftAuthentication_ClientSecret>As found in license and ticket</MicrosoftAuthentication_ClientSecret> <FacebookAuthentication_ClientId>As found in license and ticket</FacebookAuthentication_ClientId> <FacebookAuthentication_ClientSecret>As found in license and ticket</FacebookAuthentication_ClientSecret> <GoogleAuthentication_ClientId>As found in license and ticket</GoogleAuthentication_ClientId> <GoogleAuthentication_ClientSecret>As found in license and ticket</GoogleAuthentication_ClientSecret> <LicenseToken>yourkey</LicenseToken> </root>
You get the needed information from MDriven Portal:
Fully local – development or production
In some scenarios it might be beneficial to run layer 3 (the MDriven Server) locally as well. This may be the case if your data is not allowed off premises due to cloud trust issues in your organization.
You then install a MDriven Server instance and point your App_Data/MDrivenServerOverride.xml setting towards it.
The default layer 4 for MDriven Server is a SQLServer CE database – but you can change this to any other SQLServer you have a connection string to. MySql is also supported.
This is how:
Get the full architecture of MDriven Turnkey explained
To make your experience more comfortable, we set the main tags mentioned in the video to the right bar menu of this mini player. Choose the interesting subtitle on the list and immediately get to the exact theme navigation-itemplace in the video. Now you can pick any topic to be instructed without watching the whole video.