157

Do you have any particular style of organizing projects?

For example, currently I'm creating a project for a couple of schools here in Bolivia, this is how I organized it:

TutoMentor (Solution)
TutoMentor.UI   (Winforms project)
TutoMentor.Data (Class library project)

How exactly do you organize your project? Do you have an example of something you organized and are proud of? Can you share a screenshot of the Solution pane?

In the UI area of my application, I'm having trouble deciding on a good schema to organize different forms and where they belong.

Edit:

What about organizing different forms in the .UI project? Where/how should I group different form? Putting them all in root level of the project is a bad idea.

8 Answers8

112

When designing a project and laying out the architecture I start from two directions. First I look at the project being designed and determine what buisness problems need to be solved. I look at the people who will be using it and start with a crude UI design. At this point I am ignoring the data and just looking at what the users are asking for and who will be using it.

Once I have a basic understanding of what they are asking for I determine what the core data is that they will be manipulating and begin a basic database layout for that data. Then I start to ask questions to define the business rules that surround the data.

By starting from both ends independently I am able to lay out a project in a way that melds the two ends together. I always try to keep the designs separate for as long as possible before melding them together, but keep in mind the requirements of each as I move forward.

Once I have a good solid understanding of each end of the problem I begin to lay out the structure of the project that will be created to solve the problem.

Once the basic layout of the project solution is created I look at the functionality of the project and set up a base set of namespaces that are used depending on the type of work being done. This may be things like Account, Shopping Cart, Surveys, etc.

Here is the basic solution layout that I always start with. As the projects get better defined I refine it to meet the specific needs of each project. Some areas may be merged with others and I may add a few special ones as needed.

SolutionName

.ProjectNameDocuments
    For large projects there are certain documents that need to be kept with
    it. For this I actually create a separate project or folder within the 
    solution to hold them.
.ProjectNameUnitTest
    Unit testing always depends on the project - sometimes it is just really 
    basic to catch edge cases and sometimes it is set up for full code 
    coverage.  I have recently added graphical unit testing to the arsenal.
.ProjectNameInstaller
    Some projects have specific installation requirements that need to be 
    handled at a project level.
.ProjectNameClassLibrary
    If there is a need for web services, APIs, DLLs or such.
.ProjectNameScripts (**Added 2/29/2012**)
    I am adding this because I just found a need for one in my current project.  
    This project holds the following types of scripts: SQL (Tables, procs, 
    views), SQL Data update scripts, VBScripts, etc.
.ProjectName
    .DataRepository 
        Contains base data classes and database communication.  Sometimes 
        also hold a directory that contains any SQL procs or other specific 
        code.  
    .DataClasses
        Contains the base classes, structs, and enums that are used in the 
        project.  These may be related to but not necessarily be connected
        to the ones in the data repository.
    .Services 
        Performs all CRUD actions with the Data, done in a way that the 
        repository can be changed out with no need to rewrite any higher 
        level code.
    .Business
        Performs any data calculations or business level data validation,
        does most interaction with the Service layer.
    .Helpers
        I always create a code module that contains helper classes.  These 
        may be extensions on system items, standard validation tools, 
        regular expressions or custom-built items.  
    .UserInterface
        The user interface is built to display and manipulate the data.  
        UI Forms always get organized by functional unit namespace with 
        additional folders for shared forms and custom controls.
Adam C
  • 3
  • 3
Amy Patterson
  • 2,226
  • 1
  • 16
  • 15
  • Best answer so far! –  Feb 04 '11 at 16:01
  • Enjoy the bounty, your answer helped me out tremendously. –  Feb 05 '11 at 23:01
  • Bounty well deserved! Good job on the comments under each node. A good idea to save this as a VS template project :) – invert Feb 07 '11 at 06:27
  • I store my folder structure of all my projects like so: a:\Source\VS2010\Web\Apps or a:\source\vs2010\WPF\Apps a:\source\vs2010\Silverlight\Apps as well. – Rick Ratayczak Feb 09 '11 at 15:46
  • the dots before the names Directory ? – explorest May 12 '11 at 14:34
  • @explorest the dots just indicate that that item is a project inside the main solution. – Amy Patterson May 13 '11 at 13:42
  • 3
    @Amy they're all projects? Or just the top-level items? I'm fairly new to .Net and have trouble deciding whether something should be a project or a sub-folder of a project. – Carson Myers Jul 07 '11 at 04:15
  • 1
    @Carson Myers each of the top level items are projects, the second level items are folders within a project. Some of the top level items are projects that are compiled into dlls that are referenced by the other projects as needed. – Amy Patterson Jul 07 '11 at 14:30
  • 3
    @Amy I liked your answer very much, very detailed explanation. But I've seen in some examples people dividing DataRepository, DataClasses, Services, Business, etc into different projects instead of different folders in the same project. What would you say regarding this? What are the advantages/disadvantages between the two options? Thanks! – empz Apr 04 '12 at 19:20
  • @emzero It depends on the project. For smaller projects I tend to do the folder option. For larger ones I tend to go with more of project/web services option. The benefit to the way it is above is that I can deploy the web services to different servers. The project I am on right now has some pretty serious firewalls and this model allows us to have more flexibility when it comes to where our data lives. – Amy Patterson Apr 10 '12 at 19:23
  • @Amy - something has changed in the last 4 years :) ? In addition, many times when retrieveing something from DB you need to manipulate it a bit (convert from JSON to objects, do some tricks) - do you do it in the "Services" layer? like .convert() on the result from DB? – user1025852 Mar 11 '15 at 09:20
70

I like dividing my projects into layers

That way it's easier to manage cyclic dependencies. I can guarantee that no project is importing the View project (layer) by mistake, for example. I also tend to break my layers in sub-layers. So all my solutions have a list of projects like this:

  • Product.Core
  • Product.Model
  • Product.Presenter
  • Product.Persistence
  • Product.UI
  • Product.Validation
  • Product.Report
  • Product.Web

They are the bigger "building blocks" of my application. Then inside each project I organize in namespaces more logically but it varies a lot. For UI when creating a lot of forms I try to think in a spacial division and then create namespaces for each "space". Let's say there's a bunch of user preferences user controls and forms, I'd have a namespace called UserPreferences for them, and so on.

Alex
  • 3,228
  • 1
  • 22
  • 25
  • What about: Product - Core - Model - Presenter - Persistence - UI - Validation - Report - Web – Daniel Fisher lennybacon Jul 10 '14 at 08:34
  • I feel that `Core` is quite dangerous, because it leads to a monolithic code design, where most logic may or may not go inside `Core`. For example: Logic that does not sounds like a Model, Presenter, Persistence, UI, Validation, Report, Web, will naturally get thrown to `Core`. – Yeo Nov 01 '15 at 11:38
  • @Yeo This can play both sides, either by turning your `Core` project to a monolithic piece of garbage or by saving you from having a solution containing hundreds of projects. It's the developer's responsibility to take on that decision, no project structure can save bad coders from doing bad things. – Alex Nov 06 '15 at 16:58
  • I wander which one of those projects is meant for business logic? Is it Product.Core? – Prokurors Mar 25 '16 at 22:12
  • 1
    @Prokurors yes, usually inside Product.Core is where I put the "core" business logic of the system. The "ui business logic" should go in Product.Presenter. For example, if your system decides that a button must be disabled while certain data is loading, that's what I call a "ui business logic" and I'd put that in the presenter. The "core business logic" is something directly related to your core model (or domain model). A messaging system might decide the max number of characters is 140 characters, that's a logic that belongs to the core of your business. – Alex Mar 27 '16 at 13:59
  • 2
    how is Product different from UI or Web? – dopatraman Sep 28 '16 at 20:22
19

Organizing Projects

I typically try to divide up my projects by namespace, like you say. Each tier of an application, or component is its own project. When it comes to how I decide how to break my solution up into projects, I focus on reusability and dependencies of those projects. I think about how other members of my team will be using the project, and if other projects we create down the road may benefit from using some component of the system.

For example, sometimes, just having this project, which has an entire set of frameworks (email, logging, etc) is sufficient:

MyCompany.Frameworks

Other times, I may want to break out frameworks into pieces, so that they can be imported individually:

MyCompany.Frameworks.Networking
MyCompany.Frameworks.Logging
MyCompany.Frameworks.SomeLOBFramework

Organizing Forms

Organizing Forms under a UI project will really morph as your project expands.

  • Small - A simple Forms folder could suffice for a very small project. Sometimes you can overengineer structures just like you can namespaces and make things way more complicated than they need to be.

  • Medium to Large - Here, I usually start dividing my forms into functional areas. If I have one part of my app that has 3 forms to manage a user and some that keep keep track of soccer games and scores, then I'll have a Forms > User area and a Forms > Games area or something like that. It really depends on the rest of the project, how many forms I have as to how fine-grained I break it up.

Remember, at the end of the day namespaces and folders are just there to help you organize and find things faster.

Really, it depends on your team, your projects, and what's easier for you. I would suggest that in general, you make separate projects for each layer/component of your system, but there are always exceptions.

For guidance on system architecture see Microsoft's Patterns and Practices site.

Ryan Hayes
  • 20,139
  • 4
  • 68
  • 116
11

When I write code in .NET, there is a clear tendency to have clusters of related functionality. Each of which may have some sub-sets of the same. I like to break out the main groups physically - one of these per VS project. I then further subdivide logically using assemblies. Following this pattern, one of my current projects looks like this:

  • Wadmt (solution)
    • Wadmt.Common
    • Wadmt.Data
      • Wadmt.Data.MySql
      • Wadmt.Data.SqlServer
      • Wadmt.Data.Oracle
    • Wadmt.Domain
    • Wadmt.Services
    • Wadmt.Tests
      • Wadmt.Tests.Common
      • Wadmt.Tests.Domain
      • Wadmt.Tests.Services
      • Wadmt.Tests.Integration
    • Wadmt.Web

Hopefully that is useful to you. The levels of separation took me some time to figure out.

Grant Palin
  • 1,721
  • 2
  • 14
  • 28
7

It's good to have a plan for organizing your solutions, and there are several ways of doing it. We have some functionality that is shared across multiple projects, which also provides consistency for our users. The project organization does depend on what we are doing. At it's core we will have:

Company (solution)
  Company.Common (shared library)
  Company.Project (Main application UI)
  Company.Project.UnitTests (Unit tests for all project modules)
  Company.Project.IntegrationTests (integration tests for all project modules)
  Company.Project.AutomationTests (tests that invoke the UI)

From there it really depends on the setup. If we have both a client application and a web front end (useful for collecting usage results in classroom or other research), we need a project that has the commonly shared code (i.e. the data objects that will be serialized).

  Company.Project.Model (ORM and business logic layer)
  Company.Project.Webapp (Web frontend/web service layer)
  Company.Project.WebClient (client code for web services)

Other subprojects may be added as necessary. As I said, it really depends on the project. Some projects are really simple, and only need core elements. We do try to fight arbitrary project separation, so dividing by layers really makes sense. The layers are defined by what needs to be shared across projects, solutions, or what needs to be plugins/extensions.

Berin Loritsch
  • 45,784
  • 7
  • 87
  • 160
  • AutomationTests implies that unit and integration tests are done manually. It's not really clear what is meant by it without reading comments. – HamsterWithPitchfork May 09 '20 at 08:21
  • Application testing outside of the automation and integration tests can be automated or manual. We have mostly automated regression testing, with a couple areas that are still manual. That lets us catch when user facing functionality was accidentally broken. – Berin Loritsch May 09 '20 at 16:22
6

It’s Interesting that so many people don't consider DRY here. It happened a few times in my life that developers created directory structures that weren't able to build because of that. Keep the project name out off solution and project directories!

So here is my way:

{drive}:\{customer}\{apps|libs|tools}\{project}
  - cer
  - res
  - src
   - Common
   - Data
   - UI
   - Logic
   - Logic._Tests
Daniel Fisher lennybacon
  • 161
  • 4
  • What's `DRY`? Abbreviation for something? – Pithikos Aug 21 '14 at 15:47
  • 1
    @Pithikos It's an acronym for [Don't Repeat Yourself](http://en.wikipedia.org/wiki/Don't_repeat_yourself) – Pero P. Sep 25 '14 at 18:51
  • 2
    what is `Logic`? couldnt there be logic in the `Common` folder as well? – dopatraman Sep 28 '16 at 20:24
  • 1
    I put resuable stuff into Common. Some might say Framework or Core as well... – Daniel Fisher lennybacon Sep 30 '16 at 19:57
  • What is cer? Why is there underscore before _Tests? Why is lower and upper case mixed (cer, res; Common; Data)? I agree that project and company name should be excluded from project names, because that is redundant, but this structure you've listed isn't self explanatory, it brings more questions than clarity. – HamsterWithPitchfork May 09 '20 at 08:25
  • `cer` holds certificates and keys. The under dash keeps the test next to its project. The lowercase is the `default` structure. The uppercase an example for .NET/C#. Other languages like e.g. JavaScript would use lowercase and hyphens. – Daniel Fisher lennybacon May 11 '20 at 07:59
2

When I'm designing my application, I always see it as modules with some dependencies between them. When I have a design in mind, then I use a bottom-up strategy to develop it. I develop each module and then I get them working together.

Well, those modules are projects under my solution (usually class libraries). Each module has a different namespace and its own design (containing classes, etc).

One of those modules is the GUI (Graphical User Interface).

I also always use a Revision Control tool to track the changes in each project. I suggest Git. It's opensource, distributed and free to use.

Oscar Mederos
  • 1,006
  • 7
  • 20
1

Each time I start on a new project I get a broad specification of what it is supposed to do. Having this input helps me by providing me of a context, therefore I go ahead and think the best (or most appropriate) method to achieve the projects goals. At this point I start thinking in which design patterns may help me provide the intended solution. Here is where I start organizing the project, taking into account the design patterns I will adopt for the project.

A couple of examples:

  1. If the project only refers to building input data screens. Most probably I would use an MVC pattern.
  2. If the project is going to be used as a heavy duty UI which most support multiples platforms, an MVVM design pattern becomes helpful.

Have in mind that each of this will force you to organize your project on a specific way.

Here is some reading for you:

.Net Design Patterns.

Design Patterns.

Object Oriented Design.

Hope this helps.

Community
  • 1
El Padrino
  • 111
  • 2