I am creating a new project from scratch and have decided to use a 3-layer model.

I am using:

  • the 1st layer for business entities,
  • the 2nd layer for business logic,
  • and the 3rd layer for data logic layer.

Do I need to create different projects for these different layers or do I need to create different folders in one project?

What are the pros and cons of both approaches?

  • Why separate Business Logic from the Business Entities? You can add the logic to the entity directly to prevent anyone from circumventing the logic. For example a SubscriberList entity can have a AddSubscriber(Person person) method which can now make sure a person can only be added as a subscriber if Person.Age >= 18. If you have the logic outside the entity you cannot guarantee that the rules is always enforced.
    – Nope
    Jul 1, 2013 at 13:37

3 Answers 3


I would most definitely create 3 separate projects for each layer you hope to create. By using separate projects it makes your solution much more discoverable and maintainable.

To read a bit more on when to divide up projects see this answer

In the solution that you create you can make solution folders that nicely segregate the projects into more manageable areas.

You can have solution folders that are named after each layer you want to create.

  • Business Entity
  • Business Logic
  • Data Logic Layer



The practice of putting each layer of your application in a separate project is a common one in the .net world, and is viewed by some as a "best practice," but in my experience, it actually causes more problems than it solves. In particular:

  • It makes it harder to upgrade third-party references, since you can all too easily end up with references to two different versions of the same assembly. NuGet alleviates the problem to an extent, but in my experience it doesn't eliminate it altogether.
  • It slows down compilation times.
  • It causes problems with circular dependencies: sooner or later there will be a set of classes that you have to add to your code, only to find that you're not sure whether they belong in your business layer, your DAL, or somewhere else altogether. Chances are high that you'll get this wrong for some reason the first time round and have to move them to a separate assembly, thereby compounding the problem.
  • It forces you to jump around through widely separated parts of your solution to follow through the flow of your code.

Putting your different layers into separate assemblies is also a violation of the Common Closure Principle, which says that classes that change together should be packaged together. Asssemblies -- and therefore Visual Studio projects -- are a unit of deployment, not a unit of organisation. If you want to organise your code by different layers, that's what namespaces are for.

  • So really instead of projects, folders would be better?
    – herrozerro
    Nov 8, 2015 at 16:20
  • 1
    If you mean folders within the same project, and therefore namespaces, yes. If you mean solution folders, in general, no.
    – jammycakes
    Nov 9, 2015 at 9:22

It's generally a good idea to separate the aspects of your product in separate components and extract them to independent modules as much as possible (or projects, if you want).

However, it's not necessarily as easy to do in all languages, as the level of tooling at hand may vary greatly and a lower-tech solution might be a good compromise between a decent design and pulling your hait out for hours to make your build comply to an ideal architecture.

Considering your added the C# tag, which I left as I think that helps to assume the tooling you have, though it really isn't relevant to the language, I'd indeed recommended to separate your project in 3 projects as part of a single solution.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.