Hello guys.
I was wondering here, how do you guys organize your projects, in terms of funcionality, scope, etc.
Do you have one project for unit tests, one project for class library code, one project for User Interface?
Or do you just divide all these into separate folders?
I ws thiniking that separating these by projects is easier, because your central code library is at one place, without direct references to the UserInterface (no WinForms dependencies) or the UnitTests.
Any opinions?
Do some searches on Stack Overflow and on Google--there are others who have asked the same question.
Some considerations:
Visual Studio takes longer to compile solutions with many projects, than single large projects. Don't divide your solution up too finely.
Microsoft's Composite Application Guidance has an interesting way of dividing up projects. There's an Infrastructure project, a bootstrapper project, and then projects for each "module" of code.
Currently I'm working on a project that divides the projects up just like your example: infrastructure, business logic, GUI, and unit tests.
I prefer to organize files by purpose, not type. For example, I create folders called "Communication" and "Interop" rather than "Events" and "Interfaces".
Do you have one project for unit tests, one project for class library code, one project for User Interface?
Pretty much this. Typically keep the UI lean and move any business logic into its own project(s), with one test project per business logic project.
I break up projects by assembly type as you described. It's good to at least have the main project that's executable (if it's an application) and one or more class libraries. If it is a windows app, definitely try to separate the UI from the code as much as possible. WPF apps do a wonderful job of accomplishing that.
Other than that, some other advice I could lend is definitely collect some third party class libraries and write some of your own when code reuse is obvious or apparent.
I try to divide projects into what you might call "deployment units." In other words, "How might I deploy these assemblies?"
Because I'm obviously not deploying unit tests, they are in their own project.
I then divide UI and "business logic" into separate projects. If I keep those lines of separation clean, I can replace my UI layer with a new technology or infrastructure (think WPF vs. ASP.NET) and still reuse the "business logic" assemblies for both. I just introduce a new UI layer that understands the business logic interface.
I also try to keep a separate library for code that I might share between solutions. This would be my data access utilities, file parsing utilities, and others that I use over and over as I build projects. I can just include those assemblies into my new solutions and I get all of that functionality that I've already invested my time in.
Hope that helps.
Last few projects I've been involved in - we ended up with the following structure (All WPF Prism projects):
xxx.Shell.Exe
xxx.yyyModule.dll (x 4-7)
xxx.Tests
xxx.Model
xxx.Common
And for those that use WCF - add:
xxx.Backend
xxx.DataContracts
All in one solution (we live with the long build-times...) Dividing it up into seperate solutions introduced too many problems when refactoring. So far - it has worked great for us.
A few patterns I've found useful in organizing projects within a solution:
I almost always have a "common" or "utils" project. This project should have very few dependencies, so it can be easily re-used anywhere and everywhere in my solution (or possibly in other solutions). You be surprised how many little helper classes will fall into this project.
I always try to separate my business logic into one project (or more likely a set of projects), and my bootstrap/provider code into a different project (or set of projects). My bootstrap/provider classes are context-specific (they can assume the presence of an HttpContext or command-line args, etc.), but they contain no business logic. My business classes implement the business logic, but do not assume the presence or absence of any context-specific elements. That way, if I initially build the system as a console app, I can later write a set of windows-service bootstrap/providers, and very quickly transform it into a windows service with minimal-to-no impact on the business classes.
Similar to bootstrap/provider classes, I also try to isolate my data layer from my business classes. But that's a common, basic separation that everyone has heard 1000 times, so it's hardly even worth mentioning.
Many systems' business logic is too complex to fit into a single project and keep a degree of code maintainability. Thus, I usually find myself with multiple business logic projects, grouped by functional area ("customer mangement", "product inventory", etc.).
I go something like this in terms of projects within a solution:
Administration -- General documentation, master copy of license, etc. I'll usually also make this compile to a small command-line "readme" application that displays the license, revision notes, etc.
Data -- General data, such as XML etc. No compileable code.
Library1 ... LibraryN -- One or more libraries (usually 1-3: utils, core, extended code).
Application1 ... ApplicationN -- Application (usually one).
Test1 ... TestN -- Tests.
Within each project, I keep the files for each namespace in separate folders, sub-namespaces in sub-folders, etc. I keep common types of stuff, like documentation, library or app-specific data, embedded license text, etc., in subfolders with the same name regardless of project.
-Neil
If you're doing a business-ish application with a UI, you should look into MVC.
Of course, MVC is just a general concept, but it's one that helps you make decisions of the kind that you're facing right now.
There's lots of resources on MVC in WPF, which you can probably apply directly to WinForms as well.