Question

I googled this a little but couldn't find a good result.

Right now I'm building a web site and I'm trying to make it as correct as possible from a design point of view from the beginning.

The problem I'm now facing is that when deciding to start with logging I needed a project to place this code in. As I could not find a suitable place in my currect projects I thought: hey, why not a logging class library?

Is there a general guideline on how many projects you should have? I know this would be a rather small project but it would be nice to entirely get it out of my way!

Any hints are appreciated :)

Was it helpful?

Solution

Absolutely you should have a logging library. And if you're going to make this as 'correct as possible from a design point of view' and your proect is less than trivial then you should definitely have some number of projects. The thing is, we have no idea what you're working on besides the fact that it's a web app. It's the biz domain that often determines how complex your solution has to be.

OTHER TIPS

I'd go for a three-tier architecture for a small project.

This would include:

  1. Application Layer
  2. Business Layer
  3. Data Layer

but if you want to add logging, it would be best to create another project. This would also help you so that if you want to add logging to another application, you can just include the logging project.

Either way would work, if you are concerned about project limit in a solutions. Don't be.

I myself would put it in a separate project or a utility project.

We have a solution with 200+ projects. The downside is long load time in Visual Studio. But past that the only issue is making sure you have enough RAM.

Also, MSBuild.exe has built-in support for SLN files, so look into using that instead of Visual Studio if you are doing automated builds.

"That which changes together should be packaged together", I forget where that guideline comes from (Code Complete maybe?).

In other words your assemblies (projects) should represent a coherent abstraction in the same way your classes/objects do at a lower level.

So yes, a separate logging project is the right way to go (although do check out log4net or Microsoft's logging block before you roll your own!)

Put a logging into a separate project is perfectly fine.However it really depends on the scope of your project.I normally setup my project like this

YourProject.Web(web project)

YourProject.Core(all the business logic)

YourProject.Web.Tests(Watin tests)

YourProject.Web.Core.UnitTests(Unit tests)

YourProject.Web.Core.IntegrationTests(Integration tests)

I suggest you to download some open source Project from asp.net to see how the project have been organized.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top