0

I have been having a discussion with a colleague about the best way to organize a (C#)project after he reorganized a project I had been working on from something that looked like this:

Combined

To something that looks like this:

enter image description here

I tend to sway towards having a few big projects as opposed to many smaller projects, but I am open to new ideas and I would love for some input on this. Does anyone have experience with either of these approaches either really working out, or completely falling apart a few years down the line?

  • Welcome to programmers. It not necessary to add salutations or sign-offs to your question. Those are generally regarded as clutter here. – Bart van Ingen Schenau May 7 '14 at 15:56
  • 2
    What arguments did your team mate make for his approach? In some of my larger projects, I have used folders within a class library to organize classes rather than multiple projects. So I would be interested in his reasoning for using projects instead. – Charles Wesley May 7 '14 at 16:36
3

A benefit of having many smaller, cohesive projects is reuse. If you have a project B that needs project A for 5% of the things, perhaps that 5% of things should be split out into its own project C which B should depend on instead, if it is really an independent feature or logical grouping of code. Part of the "interface segregation principal" is that a class should not be forced to rely on an interface for methods it does not care about, i.e. interfaces should be small and cohesive. You can think of this project refactoring as an extension of that.

On the other hand, being practical trumps good design and project organization. If you dont think that splitting up your projects to allow easier refactoring or reuse by other projects in the future will be beneficial (ex. you dont expect your project to get reused), then time (i.e. money) shouldnt be spend doing that refactoring if it is non-trivial.

  • +1 for the last paragraph. Splitting up the projects adds complexity to project references and deployment, increases build times, and (in general) increases the total application/library size. This is a case of YAGNI - it's easy enough to split the projects later if necessary, but you are better off not doing so until it is. – Dan Lyons May 7 '14 at 17:19
  • Thank you very much, this is the conclusion that me and my team mate came to about 5 minutes before your answer. I am especially interested in the small cohesive interfaces, this will give me a lot to think about. – Zach Spencer May 7 '14 at 17:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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