Hopefully a relativity simple question. I'm starting work on a new internal project to create tractability of repaired devices within the buildings.

The database is stored remotely on a webserver, and will be accessed via web API (JSON output) and protected with OAuth. The front end GUI is being done in WPF, and the business code in C#.

From this, I see the different layers Presentation/Application/Datastore. There will be code for managing all the authenticated calls to the API, class to represent entities (business objects), classes to construct the entities (business objects), parts for WPF GUI, parts of the WPF viewmodels, and so on.

Is it best to create this in a single project, or split them into individual projects?

In my heart I say it should be multiple projects. I have done it both ways previously, and found testing to be easier with a single project solution, however with multiple projects then recursive dependencies can crop up. Especially when classes have interfaces to make it easier to test, I've found things can become awkward.

  • 1
    I would seperate them into what makes sense for the project.
    – Ramhound
    Commented Oct 6, 2011 at 14:22
  • Does anybody else have any thoughts, one on project for holding the interfaces as MattDavey suggested. I used this approach before in order to avoid the mentioned dependencies. Or should the interfaces for class x, sit in the same project as class x.
    – JonWillis
    Commented Oct 6, 2011 at 16:10
  • Also, what layers do you all uses. I've seen a few different varities although the main ones are Presentation/Application/Infrastructure. Some also split application into 2 parts, application + service. Some models also mention a specific layer for business logic, which to me could be included in the business objects themselves.
    – JonWillis
    Commented Oct 7, 2011 at 11:20

8 Answers 8


It depends on the size of the project

Here's the guidelines I tend to use

  • A small project, with a handful of pages or less, I almost always keep to a single project.

  • If the small project's Data Access layer is large or complex, I might separate that out into it's own layer, but otherwise it just sits in its own folder.

  • If the project is bigger, I'll almost always have a separate project for the DAL, and any further splitting depends on where the boundaries between the application's functionality lies.

  • If the application has multiple purposes, each with it's own views, viewmodels, etc, then I'll usually separate each piece into it's own area. If each section is small, I separate them by a Folder. If each section is large, I'll separate them by a project.

  • If I have multiple projects that need to reference the same set of objects (ViewModelBase, RelayCommand, etc), I'll create a project just for the shared infrastructure objects.

  • If I have a large amount of shared custom styles/templates/resources, I'll create a project just for those.

As a side note, I made a mistake with my first large WPF project and separated them by putting Models in one project, Views in another, and ViewModels in a third. I can tell you now that's not the way to go, since maintenance becomes a nightmare :)

  • Curious, what maintenance issues did you have by separating the layers?
    – Ian
    Commented Oct 7, 2011 at 9:45
  • @Rachel, I will be using WPF. So would be interested to know how you organised the project in then end. I think I can remember a small MVC project been a pain when separating 3 parts into 3 dlls. For WPF, My view will be the GUI, the entity/business object to be changed, and the ViewModel the interaction between them. The ViewModel would deal with the logic of calling a repository to load/save the repairs (which in turn have factories/web apis, etc).
    – JonWillis
    Commented Oct 7, 2011 at 11:18
  • 1
    @Ian The biggest issue was that most minor changes, such as adding a single field, required me to hunt down the Model, View, ViewModel, and DAL in 4 separate libraries. The project I was working at the time was fairly large, and I wasted more time than I care to looking for specific files. Since then I've changed to keeping related objects together, so for example anything Search-Related such as SearchView, SearchViewModel, and SearchResultModel would all be grouped together in a folder and I've found it makes the app easier to maintain.
    – Rachel
    Commented Oct 7, 2011 at 11:35
  • @Ian I also recall having dependency issues and running into circular references, because despite my best efforts some layers needed to reference others, but that layer was referencing them, so I had some ugly workarounds until I refactored
    – Rachel
    Commented Oct 7, 2011 at 11:35
  • 1
    @JonWillis Most of my WPF projects are broken out based on the points specified in my answer. Usually the DAL is its own layer, and each Module, or Section of the project is grouped together (either in it's own folder, namespace, or project depending on the size of the project). So for example, all the Search Objects would be together, including the Interface for the data layer, but the actual data access layer for the Search would be in the DAL library. Quite often I have an Infrastructure or Common library which contains common base classes, interfaces, and helper classes.
    – Rachel
    Commented Oct 7, 2011 at 11:39

I've seen the best results with one project per layer, plus a testing project per layer. I have seen few applications that cannot be accomplished in 10 or fewer projects in the solution, where the solution encompasses everything.

Don't fall into the trap of using projects where you really want namespacing. Tons of projects adds nothing but overhead for no gain.


IMHO seperate is almost always better. I almost always seperate out my data layer unless the project is 100% trivial. The reason is because the data layer tends to get passed around the most often. Rarely will you hook up a GUI to multiple data layers and expect it to function well. The much more common scenario is that you have a single data layer, and you want it to be distributed out across multiple GUIs (ASP.Net, WPF, and a Silverlight app for example). It is awesome when you can just build the data layer project and put that dll in as a reference in the next GUI you build.

  • +1 When I'm starting new projects I quite often build a simulated data layer which holds the data in memory. Allows me to get on with building the rest of the app first. Then I can swap it out for a "real" data access layer later..
    – MattDavey
    Commented Oct 6, 2011 at 15:05
  • Would you consider entities (DTO), factorys, and classes used to communicate with the web server all part of the data layer?
    – JonWillis
    Commented Oct 6, 2011 at 16:14
  • @JonWillis - No, probably not all of those. I would put the factories and classes for the webserver in a namespace of a class library project. My typical data layer contains nothing but the necessary dbml files and/or edmx files. As a rule, however, I do give "library/framework" stuff their own project. They definitely don't need to be thrown in with the GUI project, although I do see people do that all the time.
    – user3792
    Commented Oct 6, 2011 at 17:17
  • Realistically though, how long would it take you to take a few namespaces, and branch them out into a new project. I feel it's a pretty easy refactoring job.
    – Didier A.
    Commented Jun 12, 2014 at 19:26

For me, 4* is the magic number. One project for each layer, and one project which defines all the interfaces/DTO's needed to communicate between them.

*7 if you count unit tests


I've always used a single solution if I'm working on those different layers, or if there is tight coupling with them. I want to hit F5 and have all the projects get rebuilt if needed. I don't think there is a "right" way to do it.


Its personal taste, the most important thing is to be consistent. I personally have a seprate project for each layer of the application so the separation is obvious.

  • Which layers do you separate down to? Do you have separate Application/Services layers, and if so how do they actually differ. Is your business logic contained within application/service, or are they methods on the actual business objects?
    – JonWillis
    Commented Oct 7, 2011 at 11:13

The increase in number of projects has to do with enabling unit testing and simplifying the dependency graph to the point where things aren't so complex that changes in one part of the app break things in seemingly unrelated parts of the app.

It works out when I am doing some sort of dependency inversion, to put all the "contracts", interfaces, abstract classes, data transfer objects into one assembly. In another assembly I put anything that talks to the database. Unit tests get their own assembly. If the UI is fundamentally untestable (e.g. ASP.NET winforms), then there is significant benefit to splitting the UI into testable code and untestable code-- an assembly each. Sometimes some code starts to show up that has nothing to do with the database, the UI or anything I've mentioned so far-- it's code I sort of wished was in the .NET framework. That code I will put into a utilities assembly, or at least put it in whatever the root assembly is (probably the one with the interfaces.

If all assemblies reference all assemblies, or nearly so, then they should be merged back into a single assembly. If you or people on your team lack the discipline to keep from putting data tier code in the UI and UI in the data tier, then simplify things by merging it all back into a single layer.

Some editions of Visual Studio runs into performance problems at about 15 assemblies, sometimes it depends on what kind of project are there. Strategically unloading project files can sometimes help though.

  • I'm the sole developer at the company, at the moment. And also fresh out of university, so trying to instill good practices, on the larger projects as soon as possible. I'm interested in making it maintainable because the system specification has changed so much before i even began to document it, against the requests of wanting the system asap. In your opinion, would have an assembly which contains only interfaces be a suitable solution? That way dependence should only be on the interfaces and factory classes.
    – JonWillis
    Commented Oct 7, 2011 at 11:11
  • 1
    Yes. It's better to understand the motivation of assembly splitting, but if you (or your team members) don't grok it, its still a inexpensive maneuver. So even if you end up with all assemblies dependent on all assemblies and no hope of unit testing, moving things that behave like contracts (interfaces, abstract classes) to their own assembly, is a step in the right direction, and has few downsides. Commented Oct 7, 2011 at 16:18

The only good reason to have more than one project, is if you need to share a set of classes and files across multiple applications.

If projects are used by only one application, they shouldn't have been made in the first place. Use namespaces instead. Save yourself the trouble of circular references, dll overhead, and project confusion when looking for files.

Read this article for a better more in depth explanation of why that is so: http://lostechies.com/chadmyers/2008/07/16/project-anti-pattern-many-projects-in-a-visual-studio-solution-file/

And as the article states, I'd welcome anyone who has a valid reason to have multiple projects apart from code sharing across application to tell me what it is, because I doubt there is any.

  • 1
    Counter Arguments on downvote would be appreciated.
    – Didier A.
    Commented Jun 13, 2014 at 17:46

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