Here’s one more advantage of having universal (and secure) data gateway service on the server side (I’m talking about the xLim approach again): you can easily write small or large tools that simplify complex maintenance tasks.
Basically you can consider this console application to be an extremely light-weight client for the xLim 2 server architecture.
The advantages of this approach (as opposed to working directly with the database):
- The tool will have the access rights to the database that derive from the login permissions, audit log will have all events recorded for this login, all the workflows (if invoked) will be initiated by this login also (if there are permissions)
- You get low-level access to the database, but there is still no SQL to write.
- You can perform high-level operations that are not easy to do in the SQL (like spell-checking all Forms against MS Word dictionary)
- Imagine live system that uses XPO distributed caching. Normally it is not a good idea to work directly with the database, since all the changes go directly without even touching the cache. You’ll have to connect to the server anyway, since the cache will need to be notified of the changed tables. This approach, on the other side, already routes all the changes through the cache and the system will automatically stay consistent (actually the xLim2 server should not even expose the gateway to IDataLayer, but rather the cache communications, so it would be impossible to work without notifying the cache)
- In some hosting scenarios the database is not accessible outside the server. This approach does not need the direct access anyway - the gateway would do it.