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.