Store Connection/App settings in A/D
in [Framework]
|
From: milop on 29 Jan 2010 09:14 Hello. I originally posted this to the A/D group, but thought this might be a good place too. What are the pros/cons of storing connection strings and global app settings in A/D. We have a lot of applications (Windows, ASP.Net, Add-ins for Office Apps, etc) and each need to retrieve connections strings, global app settings, etc. I want a central location for this stuff and don't want to include it with every app, nor do I want to add it to each Machine.config file. I was thinking of using A/D for this. On app start up I would get the info and cache it. Any and all suggestions/comments are welcome. Thanks in advance, Mike
From: Jani J�rvinen [MVP] on 2 Feb 2010 10:23 Hello Mike, > What are the pros/cons of storing connection strings and global app > settings > in A/D. We have a lot of applications (Windows, ASP.Net, Add-ins for > Office Apps, > etc) and each need to retrieve connections strings, global app settings, > etc. To me, the Active Directory as a storage location for application settings sounds too complex for generic use. Yes, you can use it as a central store for the settings you mention, but accessing and updating (and maintaining) the settings requires too much coding in my opinion. So the question is: is there a specific requirement for you to use AD? If not, then have you thought of using a simple SQL database for this task? Some (if not all) your applications are likely to use an SQL database (SQL Server, Oracle, etc.). The server is also probably in a central location on your network, and thus you could access is easily. Additionally, there are many easy programming methods to access SQL database data. It might prove to be a better central storage for your settings than the Active Directory. Hope this helps! -- Regards, Jani J�rvinen C# MVP Vantaa, Finland E-mail: janij(a)removethis.dystopia.fi Business: http://www.nimacon.net/ Personal: http://www.saunalahti.fi/janij/
From: milop on 2 Feb 2010 16:52 Hi, Jani. Thanks for the response. The specific requirement is that there is a central store for common configuration settings. A/D seems like a logical place. Using directory services makes querying simple. As for the adminsitration of it, we would use a management console, so the coding for that end of it doesn't exist. The solution, which was supplied by Richard Mueller in the A/D newsgroup, is going to be a combination of A/D and SQL Server and A/D Connection points. Here's what Richard wrote: If you store the information locally, perhaps in the registry, then if anything changes you must update all clients. If instead the information is saved in AD you just update the one location. AD has connectionPoint objects that are saved in computer objects. SQL Server, for example, has stored procedures for publishing server instances and database as connection point objects in AD. The application can easily query AD for the connectionPoint object and retrieve connection string information from the object. If the server where the database is installed changes, for example, only the connection point object must be modified, not the registry on every client. Even if the location of the connection point object in AD changes, the client finds it by searching by application name. Thanks again Jani, Mike "Jani J�rvinen [MVP]" <janij(a)removethis.dystopia.fi> wrote in message news:uRf7CvBpKHA.1548(a)TK2MSFTNGP06.phx.gbl... > Hello Mike, > >> What are the pros/cons of storing connection strings and global app >> settings >> in A/D. We have a lot of applications (Windows, ASP.Net, Add-ins for >> Office Apps, >> etc) and each need to retrieve connections strings, global app settings, >> etc. > > To me, the Active Directory as a storage location for application settings > sounds too complex for generic use. Yes, you can use it as a central store > for the settings you mention, but accessing and updating (and maintaining) > the settings requires too much coding in my opinion. > > So the question is: is there a specific requirement for you to use AD? If > not, then have you thought of using a simple SQL database for this task? > Some (if not all) your applications are likely to use an SQL database (SQL > Server, Oracle, etc.). The server is also probably in a central location > on your network, and thus you could access is easily. > > Additionally, there are many easy programming methods to access SQL > database data. It might prove to be a better central storage for your > settings than the Active Directory. > > Hope this helps! > > -- > Regards, > > Jani J�rvinen > C# MVP > Vantaa, Finland > E-mail: janij(a)removethis.dystopia.fi > Business: http://www.nimacon.net/ > Personal: http://www.saunalahti.fi/janij/ > >
From: Jani J�rvinen [MVP] on 3 Feb 2010 10:49 Hello Mike! > The solution, which was supplied by Richard Mueller in the A/D newsgroup, > is going to be a combination of A/D and SQL Server and A/D Connection > points. Okay, sounds good to me! Maybe it's a personal preference, but I find using SQL database a snap, so that's the reason I was questioning your need to use Active Directory. In any case, the main thing is that you got a solution you can use. Let us know here in the groups if you need further assistance. Thanks! -- Regards, Jani J�rvinen C# MVP Vantaa, Finland E-mail: janij(a)removethis.dystopia.fi Business: http://www.nimacon.net/ Personal: http://www.saunalahti.fi/janij/
|
Pages: 1 Prev: Faulting module mscorwks.dll Next: IE8: How do I get Protected Mode to be on? |