How do you organize your projects?

  • 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.

    Wow, a 450 bounty!?

    @muntoo: Yeah, I'm really interested in some great answers. :)

    It should be stated explicitly that you ask about C#. I personally never see the tags.

    As always, many good questions get closed because of XYZ reasons. We might have got many other good answers.

    Agreed. SO loves to put itself as the premier resource for these kinds of things, then moderates itself out of having good information.

  • 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.
    

    Best answer so far!

    Enjoy the bounty, your answer helped me out tremendously.

    Bounty well deserved! Good job on the comments under each node. A good idea to save this as a VS template project :)

    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.

    the dots before the names Directory ?

    @explorest the dots just indicate that that item is a project inside the main solution.

    @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 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 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!

    @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 - 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?

License under CC-BY-SA with attribution


Content dated before 6/26/2020 9:53 AM

Tags used