Where to stor config file?

[=?Utf-8?B?Y2FsZGVyYXJh?=]

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

[Mr. Arnold]

>
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.

[=?Utf-8?B?Y2FsZGVyYXJh?=]

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

"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.

[-pb-]

On 31 May, 15:38, calderara <calder...@disc ussions.microso ft.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

[Mr. Arnold]

"calderara" <ca*******@disc ussions.microso ft.comwrote in message
news:2A******** *************** ***********@mic rosoft.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.

[=?Utf-8?B?Y2FsZGVyYXJh?=]

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

"Mr. Arnold" wrote:

>
"calderara" <ca*******@disc ussions.microso ft.comwrote in message
news:2A******** *************** ***********@mic rosoft.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.

[=?Utf-8?B?Y2FsZGVyYXJh?=]

I>n 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

No reaaly practicle if your work a a distributed environement especially for
Buisness and data layer.

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
"-pb-" wrote:

On 31 May, 15:38, calderara <calder...@disc ussions.microso ft.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

[Mr. Arnold]

"calderara" <ca*******@disc ussions.microso ft.comwrote in message
news:63******** *************** ***********@mic rosoft.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....x?docid=116195
http://www.microsoft.com/presspass/f...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?i...b-e0059cc82ee7

[-pb-]

On 2 Jun, 04:37, "Mr. Arnold" <MR. Arn...@Arnold.c omwrote:

"calderara" <calder...@disc ussions.microso ft.comwrote in message

news:63******** *************** ***********@mic rosoft.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....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?i...a-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.