I'm about to create a do-everything dashboard for my team and am still having second thoughts about my project/solution structure. Since this could be a long ongoing project, I want to get the structure right from the beginning.

This is what I had in mind:

  1. Create a solution named "doEverythingDashboard"
  2. Delete the project named "doEverythingDashboard" under the solution "doEverythingDashboard"
  3. Create winform project named "interface"
  4. Create console applications projects for each functionality of "doEverythingDashboard"
  5. Reference each console application in "interface"

Does this make any sense? Would it make more sense to just have one project and create a class per functionality instead of an entire project?

  • 1
    C#.net is a language. What is your application type? – Yusubov Jun 26 '12 at 15:34

Since this could be a long ongoing project, I want to get the structure right from the beginning

It's pretty tricky to know up front what the correct structure for a collection of code should be, especially where the project is essentially an R&D effort (for which read: you haven't personally built such a system before1).

So don't bother; instead, FIRST write some code, THEN look at it and consider how it might be more nicely structured. Modern refactoring tools mean you don't have to get it right first time - and who's to say there's one 'right' for all time, anyway?!

And as to your last point - create new projects (ie assemblies) exactly when you want to create new units of deployment, and for no other reason. Namespaces can provide the implementation of purely conceptual divisions perfectly well.

1 this usage is from Code Complete or PragProg or something

| improve this answer | |
  • I totaly agree with this. After doing this stuff for 20 years, I almost always have to refactor decent sized solutions when I know more about the project. – tzerb Jun 26 '12 at 15:11
  • I totally forgot to even consider how namespaces play into this. I'm mainly looking for a best practice and not looking stupid by doing what is intuitive to me (which can often times be stupid). – sooprise Jun 26 '12 at 15:16
  • 2
    +1. @sooprise, don't waste your time trying to figure out what you don't know yet. Projects do tend to call for changes in their layout as time goes by. Plus, what others think of you is none of your business. If you care so much about structuring your project the way they want, by all means go ask them what you should do. Nothing is irreversible, especially since you'll be under source control and with powerful refactoring tools at your disposal. Forget about the mythical clean history: fuck-ups are going to happen, and that's exactly how you learn. – s.m Jun 26 '12 at 17:05

Depending on your application type, you may get some hints on project structure from open source project samples. Let me mention as well an important point, as your project moves forward you may see need to slightly change the structure or add additional layers depending on requirements and design.

There are couple places where you may look at some samples:

| improve this answer | |

As mentioned above, just start writing code. BUT, if you go down the TDD route, future refactoring will be a lot easier.

There are some things to keep in mind though. Try to keep logical parts of your solution separate, eg, don't put business/domain logic in presentation layers (web/windows forms) and don't access the database/repository directly from the presentation layer/UI. Depending how complex your solution is you could use the traditional 'data access layer', 'domain entity/business logic layer', 'presentation layer' and have a project in your solution for each of these.

Some background reading that may help... http://xprogramming.com/classics/expemergentdesign/

| improve this answer | |

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