| Groups | Blog | Home |
dotnet general : Where to stor config file?
I am building a set of libraries working in a n tiers architecture Some of those libraries use common configuration settings like the database connection string and some others. I can imgaine that I can get one config file per buisness library. What is teh best way and where to store configuration files ? Should I get only one with everything in and located in a particular common folder ? Should I get many and all store in a kind of config folder ? I do not want to configure for instance data access layer from the client application app config file for security reason somehow. Thanks for your comments and help regards
[quoted text, click to view] > > Should I get only one with everything in and located in a particular > common > folder ? One XML Config file for each N-Tier layer that is needed with the file physically being at each N-Tier level with the library or executable. That's why a config file is an XML type file with tags/elements so that you can locate a particular tag/element within the XML config file and read the data belonging to the tag/element.
So if I have properly understood, I need to merge all my library settings in
a single XML config file using section group that each library will refer to get it own settings. Then I copy this single config file at every place I need it . IS that correct ? regards serge [quoted text, click to view] "Mr. Arnold" wrote:
> > > > > Should I get only one with everything in and located in a particular > > common > > folder ? > > One XML Config file for each N-Tier layer that is needed with the file > physically being at each N-Tier level with the library or executable. > > That's why a config file is an XML type file with tags/elements so that you > can locate a particular tag/element within the XML config file and read the > data belonging to the tag/element. >
On 31 May, 15:38, calderara <calder...@discussions.microsoft.com>
[quoted text, click to view] wrote: > Dear all, > > I am building a set of libraries working in a n tiers architecture > Some of those libraries use common configuration settings like the database > connection string and some others. > > I can imgaine that I can get one config file per buisness library. > What is teh best way and where to store configuration files ? > > Should I get only one with everything in and located in a particular common > folder ? > Should I get many and all store in a kind of config folder ? > > I do not want to configure for instance data access layer from the client > application app config file for security reason somehow. > > Thanks for your comments and help > regards > serge Well, I belive .net doesn't sets any standard on how to configure your data. In my opnion if you got any data which are application specific then put in app.config file of the client. By doing this you can access the configuration setting from within any classes in the project. Now regarding the database connection type of setting create the xml file within the class project and then mark that file as "Copy to Output Direcotry" . But in this case your data access class need to read this file seperatly. I hope this helps
Hoo ok sounds more logic then.
It is effectively logic and better organise to get a config file for each tiers. Now based on those tiers that you have seen, how there were organised physically ? I mean, if we talk about the buisness tiers which propose different services, how those different services are split ? are they all in a same assembly named Buisness with different class per service, or were they one assembly per buisness servcie ? How did tehy know then to which tiers the assembly or set of assembly belongs? Was it by specifying specific name space ? thnask for coment [quoted text, click to view] "Mr. Arnold" wrote:
> > "calderara" <calderara@discussions.microsoft.com> wrote in message > news:2A4488F8-7301-41DC-BCE9-74A4EC66D8CD@microsoft.com... > > So if I have properly understood, I need to merge all my library settings > > in > > a single XML config file using section group that each library will refer > > to > > get it own settings. > > Then I copy this single config file at every place I need it . > > > > IS that correct ? > > No, that is not what I am saying. > > In the N-tier solution I have seen, there was a dedicated config file for > each tier. > > One for the UI that at best had configurations that pointed to the business > tier. > > The business tier had configurations pointing to the UI and Data Access > Layer tiers. > > The DALC or Data Access Layer Component tier had a config with > configurations pointing to the Business tier with multiple connection > strings for SQL Server, based on which application needed the connection to > SQL Server. > > This was one giant N-tier solution that many applications were using the > same config files at the tiers, with *section groups* for each application. > > I can't say that's the only way it should be done, but that is what I have > seen implemented. > >
I>n my opnion if you got any data which are application specific then
[quoted text, click to view] > put in app.config file of the client. By doing this you can access the > configuration setting from within any classes in the project No reaaly practicle if your work a a distributed environement especially for Buisness and data layer. [quoted text, click to view] > Now regarding the database connection type of setting create the xml > file within the class project and then mark that file as "Copy to > Output Direcotry" . But in this case your data access class need to > read this file seperatly. This is actually what I am doing [quoted text, click to view] "-pb-" wrote:
> On 31 May, 15:38, calderara <calder...@discussions.microsoft.com> > wrote: > > Dear all, > > > > I am building a set of libraries working in a n tiers architecture > > Some of those libraries use common configuration settings like the database > > connection string and some others. > > > > I can imgaine that I can get one config file per buisness library. > > What is teh best way and where to store configuration files ? > > > > Should I get only one with everything in and located in a particular common > > folder ? > > Should I get many and all store in a kind of config folder ? > > > > I do not want to configure for instance data access layer from the client > > application app config file for security reason somehow. > > > > Thanks for your comments and help > > regards > > serge > > Well, I belive .net doesn't sets any standard on how to configure your > data. > > In my opnion if you got any data which are application specific then > put in app.config file of the client. By doing this you can access the > configuration setting from within any classes in the project. > > Now regarding the database connection type of setting create the xml > file within the class project and then mark that file as "Copy to > Output Direcotry" . But in this case your data access class need to > read this file seperatly. > > I hope this helps >
[quoted text, click to view] "calderara" <calderara@discussions.microsoft.com> wrote in message news:2A4488F8-7301-41DC-BCE9-74A4EC66D8CD@microsoft.com... > So if I have properly understood, I need to merge all my library settings > in > a single XML config file using section group that each library will refer > to > get it own settings. > Then I copy this single config file at every place I need it . > > IS that correct ? No, that is not what I am saying. In the N-tier solution I have seen, there was a dedicated config file for each tier. One for the UI that at best had configurations that pointed to the business tier. The business tier had configurations pointing to the UI and Data Access Layer tiers. The DALC or Data Access Layer Component tier had a config with configurations pointing to the Business tier with multiple connection strings for SQL Server, based on which application needed the connection to SQL Server. This was one giant N-tier solution that many applications were using the same config files at the tiers, with *section groups* for each application. I can't say that's the only way it should be done, but that is what I have seen implemented.
[quoted text, click to view] "calderara" <calderara@discussions.microsoft.com> wrote in message news:631BAC0B-1971-4B92-8FA7-68D440D622ED@microsoft.com... > Hoo ok sounds more logic then. > It is effectively logic and better organise to get a config file for each > tiers. > > Now based on those tiers that you have seen, how there were organised > physically ? > > I mean, if we talk about the buisness tiers which propose different > services, how those different services are split ? are they all in a same > assembly named Buisness with different class per service, or were they one > assembly per buisness servcie ? They were based off a Common Base Business Framework that kept things common and consistant. Each appliaction's Business Entities were derived from the base framework. So, each application had its own Bussiness Entity library which was derived from the Common Base Business Framework. [quoted text, click to view] > > How did tehy know then to which tiers the assembly or set of assembly > belongs? > Was it by specifying specific name space ? There was a Common UI Base for Web Forms, User Controls , etc, etc. For the Web Form development, all Web Forms had to be derived from the Common UI Base Form library, which was then used by the various business applications that derived their own specific forms library. Yes, there was a Common DALC Base Framework that all applications derived from as well for data access. So it made it easy to determine what application the library belonged too as well on what tier the library was functioning on, a classic Windows DNA setup. Think Company Frameworks geared towards a company's needs. http://whitepapers.techrepublic.com.com/whitepaper.aspx?docid=116195 http://www.microsoft.com/presspass/features/1999/02-23dna2.mspx Since you seem to be in this area, here is a good book to read ISBN 0-321-26820-2. If you really what know about frameworks, n-tier design and business objects, then you might want to look at CSLA, read the book, download the framework, put it together, download the project put it together and run it, to see the power and the concepts in use. http://www.lhotka.net/Article.aspx?id=1351540e-b941-446a-bacb-e0059cc82ee7
[quoted text, click to view]
On 2 Jun, 04:37, "Mr. Arnold" <MR. Arn...@Arnold.com> wrote: > "calderara" <calder...@discussions.microsoft.com> wrote in message > > news:631BAC0B-1971-4B92-8FA7-68D440D622ED@microsoft.com... > > > Hoo ok sounds more logic then. > > It is effectively logic and better organise to get a config file for each > > tiers. > > > Now based on those tiers that you have seen, how there were organised > > physically ? > > > I mean, if we talk about the buisness tiers which propose different > > services, how those different services are split ? are they all in a same > > assembly named Buisness with different class per service, or were they one > > assembly per buisness servcie ? > > They were based off a Common Base Business Framework that kept things common > and consistant. Each appliaction's Business Entities were derived from the > base framework. So, each application had its own Bussiness Entity library > which was derived from the Common Base Business Framework. > > > > > How did tehy know then to which tiers the assembly or set of assembly > > belongs? > > Was it by specifying specific name space ? > > There was a Common UI Base for Web Forms, User Controls , etc, etc. For the > Web Form development, all Web Forms had to be derived from the Common UI > Base Form library, which was then used by the various business applications > that derived their own specific forms library. > > Yes, there was a Common DALC Base Framework that all applications derived > from as well for data access. > > So it made it easy to determine what application the library belonged too as > well on what tier the library was functioning on, a classic Windows DNA > setup. > > Think Company Frameworks geared towards a company's needs. > > http://whitepapers.techrepublic.com.com/whitepaper.aspx?docid=116195http://www.microsoft.com/presspass/features/1999/02-23dna2.mspx > > Since you seem to be in this area, here is a good book to read ISBN > 0-321-26820-2. > > If you really what know about frameworks, n-tier design and business > objects, then you might want to look at CSLA, read the book, download the > framework, put it together, download the project put it together and run it, > to see the power and the concepts in use. > > http://www.lhotka.net/Article.aspx?id=1351540e-b941-446a-bacb-e0059cc... There is one more very efficient application framwork provided by Microsoft for distibuted architechture. Its called "Enterprise Development Reference Architecture". There is another document which shows how to implement this architechture and its called "Enterprise Development Reference Implementation" You can find it on MSDN site of microsoft or www.gotdonnet.com web site. If you can't then let em know and I will forward you this document. I found it very useful.
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
| home · blog · groups | Questions? Comments? Contact the dn |