I'd like to understand how I should approach using CSLA with a scenario I have in my company as it relates to SQL connection strings. As it stands today (without CSLA), when any of our applications is launched, the first thing the app does is call to a "connection" web service, passing the app's ID and the user's credentials. In return, the web service passes back the appropriate SQL connection string that should be used at that point in time. In other words, we don't put our SQL connection strings in app.config files. Our DBAs prefer this because they can move a database to another server and update the "connection service" table to point to where the database resides. The apps never have to be altered and always pick up the correct sql connection string when launched.
Are there any limitations in CSLA that would restrict me from continuing to use this process? How would I go about passing this dynamically retrieved connection string to the CSLA framework?
A simple way to approach this would be to use a ReadOnlyBase object to get the connection string at runtime - its DataPortal_Fetch() would call your web service.
Then just put the connection string in Csla.ApplicationContext.ClientContext to make it available (automatically) to all your code.
Copyright (c) Marimer LLC