First, thanks to Rocky and this community for a great resource. Upfront, I'll say I'm a relative noob at working with CSLA, but I'm very pleased with what I have learned.
I have a scenario that I'd like some input and to do a sanity check and make sure I'm on the right path.
Scenario:
I'm trying to avoid multiple business object libraries with different connection strings based on the franchise (or having to deploy the business objects everytime I add a new franchise).
My thought is to use the central database to validate a user's credentials, and based on the franchise that they belong to create a generic franchise role (ie, by City) that will be used to pull the connection string dynamically for that franchise only. I haven't tested this yet, but I would assume that the security objects are created first so that the database connection string would be available before any interaction with the business objects.
Anyone have any thoughts, better ideas, or experience something similar? Thanks!
1. The app.config file should probably have the connection string for the central database in it.
2. Then you can connect to the central DB and validate the user as you described.
3. As part of the Principal/Identity you add a connection string property which is filled during authentication.
4. Then whenever you access a BO that pulls data for a franchise you pass in the user.ConnectionString to the ADO.Net command.
5. This design let's you build the same BOs for multiple databases.
Joe
Copyright (c) Marimer LLC