Scott / wrox community -

I had a question about your thoughts on extracting web.config settings (i.e. connection strings, etc) in a layer other than the UI, like even as far down as the repository in a layered application.

In the Chapter4 Domain Model code example we have the following line in the repository:

I have always been weary of extrapolating settings from the web.config several layers down in an application. To me it feels like the lower layers expecting this data then creates a tightly-coupled feel to a specific configuration 4-5 layers up in the UI.

The wonderful effect of having the application in layers like described in your book, is how easy it would be to make the layers portable or even switch out UI technologies because the apps are so well designed into layers of responsibility. With this direct reference to a .config 4 layers up, the repository couldn't move to another UI technology since it is dependent on the web.config connection settings (without making sure the .config settings in the new technology were identical).

The alternative is to have these settings extracted at the topmost level (UI), and then passed down the layers, allowing the layers to be independent of a .config in another layer. Making each layer essentially free of dependencies from other layers, including configuration data.

What is your feeling on this topic? I know this book is ASP.NET centric and maybe the cause for assuming all UI layers will have the web.config present, but the ideas are so good and can be applied beyond ASP.NET. Have you used any other approach from mitigating these settings values down through the layers? I could be way off to on this too and calling the .config several layers up is accepted practice, and if so I am good with that too. Just wanted to see your thoughts.

This book is fantastic, A++++++++. Will be giving some 5 star reviews on it once I finish the book. Terrific work Scott!

Hi Allen,

I pick up on this point during the construction of the case study at the end of the book on page 442 (looking back I should have picked up on earlier ). You can see some code using this in the source over at codeplex:
http://aspnetdesignpatterns.codeplex.../52644#1117393

There is a slightly nicer way of doing this using the static gateway pattern, more info can be found here - http://blog.jpboodhoo.com/TheStaticGatewayPattern.aspx.

Let me know what you think about this pattern.

Thanks for the great comments, glad you are enjoying it!!!!

Cheers
Scott

Thank you for the quick response. That is exactly what I was looking for, and is similar to what I do in my applications, although abstracting the settings to an Interface is even better.

So let me ask, the interface 'IApplicationSettings'; this can be accessed by any layer in your examples that would have reference to the layer containing that Interface correct? I looked in the Agatha example source from Chapter14, and it appears the settings are only used in the Infrastructure and Controllers layer, not all the way down in the Repository layer. If we were to refactor the DomainModel example for BankAccounts from Chapter 4 to wrap the appSettings in an Interface, would you then want the Repository to add a reference to the UI layer where that interface exists? Or how would the Repository layer get access to those settings via the 'IApplicationSettings' interface? Rather should the AppServices layer maybe inject that Interface value into the constructor upon calling the Repository methods, thus providing the connection string info needed?

I looked at the Static Gateway documentation via the link you provided but didn't make this connection 1:1 to the examples I was working on currently. Any additional insight you can add to this is appreciated.

(quick note: in the Chapter4 'DomainModel' solution UI layer, there is an event named: 'btnWithdraw_Click' but the button is looking for 'btnWithdrawal_Click'. super easy fix on my side - didn't know if you wanted to know. I downloaded the code from this site (wrox).

Thanks again Scott, and nice job.

I have always put the 'IApplicationSettings' in an infrastructure project that can be accessed by any layer as I have an Infrastructure project for each application (http://4.bp.blogspot.com/_0QFX4__VHg...chitecture.JPG). The reason for using it was really to get away from magic strings and having to set up config files for my tests. I didn't want to pass it in as a dependancy as I would be passing it around all over the place and I liked the look of the static gateway pattern.I guess its personal preference on whether you want to pass it in with the constructor.

I guess the reference to the static gateway was becuase I think the application settings are noise like a logger and so I wanted a better way to deal with it rather than injecting it via the constructor.

Bugger! Missed the typo

No worries! Will be interested in any other feedback as you move through the chapters.
Scott

Yes that's perfect The Infrastructure layer seems to wrap up and take care of a lot of the generic application tasks like email, logging, configuration, etc. I like it and I agree with you that injecting the Interfaces everywhere would be a pain. Letting all layers have access to the Infrastructure layer makes sense as those operations can be used almost anywhere.

Thank you for the diagram as well; that gave a good visual to how the layer is used.

I also make a note on page 432 that you can reuse much of the code in the infrastructure project in other applications so it makes sense to maybe extract all the non application specific stuff like loggers etc into some kind of company core project so that it can be reused.