.NET - divorcing layers

Question

I am trying to create a structure for a large .NET application I am developing. I am planning to create three projects:

DataAccessLayer
BusinessLogicLayer
UserInterfaceLayer

I have two questions.

1. What would you do with functionality that is common to all three layers e.g. logging errors to a text file. Circular dependencies are not allowed in .NET. I believe the best approach is to create a forth project called Utilities.
2. Would you have .config files in all of the projects or just the user interface layer (passing all the config parameters as arguements to constructors in the BLL and DLL)

Answer 1

What would you do with functionality that is common to all three layers e.g. logging errors to a text file. Circular dependencies are not allowed in .NET. I believe the best approach is to create a forth project called Utilities.

Cross cutting concerns usually ends up in a forth assembly. But in the logger case just use one of the existing frameworks that devs are used to. for instance nlog or log4net.

Circular dependencies is a smell (high coupling or low cohesion) and should not be allowed anywhere.

Someone else suggested Dependency Injection and it's a great way to reduce coupling and therefore increase maintainability. I've written an article here: http://www.codeproject.com/Articles/386164/Get-injected-into-the-world-of-inverted-dependenci

Would you have .config files in all of the projects or just the user interface layer (passing all the config parameters as arguements to constructors in the BLL and DLL)

I would rather create an configuration abstraction. Something like IConfigurationRepository. Then it doesnt matter if the configuration is stored in web.config or somewhere else.

Answer 2

1. Having a fourth project is one solution, another is to place that in the data layer, and have methods in the business layer that lets the UI layer access them.

2. You should have each setting in one place only, so the UI layer seems to be a good place.

Answer 3

1. You could create a single logging project and add it to all the other projects but in my opinion you should add a logger configuration file for each one becouse modeling a three tier architectures as you are doing means first modeling three layers logically separated so you should be able to develop and test each of them separately.
2. if you have specific layer configuration settings(e.g. one or more layer stay on different servers for strong performance contraints required) use a different configuration file for each layer. If you have the same configuration settings you could use an only one configuration file in the user interface but be aware that if you change the user interface you will have to replace all your settings and this in my opinion might be a serious problem.

Answer 4

1. Yes, create another project for logging. I would recommend using Log4Net within that new project.

2. I would keep config settings at the top level - the UI layer - and pass anything necesssary down to the other layers.

You don't mention DI, I would definitely use DI - that should be a priority.