Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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.

share|improve this question

closed as primarily opinion-based by MichaelT, jwenting, Ampt, Bart van Ingen Schenau, Avner Shahar-Kashtan Jun 19 '14 at 11:04

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

I would seperate them into what makes sense for the project. – Ramhound Oct 6 '11 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 Oct 6 '11 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 Oct 7 '11 at 11:20

8 Answers 8

up vote 5 down vote accepted

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 :)

share|improve this answer
Curious, what maintenance issues did you have by separating the layers? – Ian Oct 7 '11 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 Oct 7 '11 at 11:18
@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 Oct 7 '11 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 Oct 7 '11 at 11:35
@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 Oct 7 '11 at 11:39

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:

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.

share|improve this answer
Counter Arguments on downvote would be appreciated. – Didier A. Jun 13 '14 at 17:46

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.

share|improve this answer
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 Oct 7 '11 at 11:11
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. – MatthewMartin Oct 7 '11 at 16:18

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.

share|improve this answer
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 Oct 7 '11 at 11:13

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

share|improve this answer

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.

share|improve this answer
+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 Oct 6 '11 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 Oct 6 '11 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. – Morgan Herlocker Oct 6 '11 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. Jun 12 '14 at 19:26

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.

share|improve this answer

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.

share|improve this answer

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