您如何组织项目？[关闭]

您是否有任何特殊的组织项目风格？

例如，目前我正在为玻利维亚的几所学校创建一个项目，这是我的组织方式：

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

您如何精确地组织项目？您是否有自己组织并为之自豪的事例？您可以共享“解决方案”窗格的屏幕截图吗？

在我的应用程序的UI区域中，我无法确定一个好的架构来组织不同的表单及其所属位置。

编辑：

如何在.UI项目中组织不同的形式？我应该在哪里/如何分组其他形式？将它们全部置于项目的根目录是一个坏主意。

在设计项目和布局体系结构时，我从两个方向开始。首先，我查看正在设计的项目，并确定需要解决的商务问题。我看看将要使用它的人，并从一个粗糙的UI设计开始。在这一点上，我将忽略数据，而只是查看用户的要求以及谁将使用它。

一旦我对他们的要求有了基本的了解，就可以确定他们将要操纵的核心数据是什么，并开始对该数据进行基本的数据库布局。然后，我开始提出问题来定义围绕数据的业务规则。

通过独立地从两端开始，我可以以将两端融合在一起的方式布置项目。在将它们融合在一起之前，我总是尽力使设计尽可能分开，但是在我前进的过程中请牢记每个设计的要求。

一旦对问题的各个方面有了充分的了解，我便开始规划将要解决该问题的项目的结构。

一旦创建了项目解决方案的基本布局，我就会查看项目的功能并设置一组基本的命名空间，这些命名空间将根据要完成的工作类型使用。可能是帐户，购物车，调查等。

这是我总是从头开始的基本解决方案布局。随着项目的定义得到更好的定义，我将其进行改进以满足每个项目的特定需求。有些区域可能会与其他区域合并，我可能会根据需要添加一些特殊区域。

解决方案名称

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

我喜欢将项目分成几层

这样，更容易管理循环依赖关系。例如，我可以保证没有任何项目会错误地导入View项目（图层）。我也倾向于将我的图层细分为子图层。所以我所有的解决方案都有这样的项目列表：

• 产品核心
• 产品型号
• 产品展示员
• 产品持续性
• 产品界面
• 产品验证
• 产品报告
• 产品网站

它们是我应用程序中更大的“构建块”。然后，在每个项目中，我都会更合理地在名称空间中进行组织，但它的差异很大。对于UI，当创建大量表单时，我尝试以空间分隔的方式进行思考，然后为每个“空间”创建名称空间。假设有很多用户首选项，用户控件和表单，我将为它们提供一个名为UserPreferences的命名空间，等等。

组织项目

我通常会尝试按名称空间划分项目，就像您说的那样。应用程序或组件的每一层都是其自己的项目。关于如何决定如何将解决方案分解为项目，我将重点放在这些项目的可重用性和依赖性上。我考虑了我团队的其他成员将如何使用该项目，如果我们随后创建的其他项目可能会受益于使用系统的某些组件。

例如，有时，仅拥有一个具有整套框架（电子邮件，日志记录等）的项目就足够了：

MyCompany.Frameworks

其他时候，我可能想将框架分解成几部分，以便可以将它们分别导入：

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

整理表格

随着项目的扩展，在UI项目下组织表单的方式会真正发生变化。

• 小型 -一个简单的Forms文件夹可以满足一个非常小的项目。有时，您可以像命名空间一样对结构进行过度设计，并使事情变得比它们所需的复杂。

• 中到大 -在这里，我通常开始将表格分为功能区域。如果我的应用程序的一部分具有3个用于管理用户的表格，而有些则可以跟踪足球比赛和得分，那么我将拥有一个“ 表格”>“用户”区域和“ 表格”>“游戏”区域或类似内容。这实际上取决于项目的其余部分，我有多少种形式以及我如何细分这些形式。

请记住，最后一天命名空间和文件夹就可以帮助您更快地组织和查找事物。

确实，这取决于您的团队，您的项目以及对您而言更轻松的事情。我建议通常，您为系统的每个层/组件创建单独的项目，但是总会有例外。

有关系统体系结构的指南，请参见Microsoft的模式和实践网站。

当我在.NET中编写代码时，很明显有相关功能的集群。每个都可能具有相同的一些子集。我喜欢从身体上划分主要群体-每个VS项目一个。然后，我使用程序集进一步细分逻辑。按照这种模式，我当前的项目之一如下所示：

• Wadmt（解决方案）
  • 共同的
  • 数据
    • Wadmt.Data.MySql
    • Wadmt.Data.SqlServer
    • 数据数据库
  • 沃顿
  • Wadmt.Services
  • Wadmt测试
    • Wadmt.Tests.Common
    • Wadmt.Tests.Domain
    • Wadmt.Tests.Services
    • Wadmt.Tests.Integration
  • 网页

希望对您有用。隔离级别花了我一些时间来弄清楚。

有一个组织解决方案的计划是一件好事，并且有几种方法可以实现。我们具有在多个项目之间共享的某些功能，这也为我们的用户提供了一致性。项目组织确实取决于我们在做什么。核心是：

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)

从那里开始，它实际上取决于设置。如果我们既有客户端应用程序又有Web前端（可用于收集课堂或其他研究中的使用结果），则我们需要一个具有共同共享代码（即将被序列化的数据对象）的项目。

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

可以根据需要添加其他子项目。正如我所说，这实际上取决于项目。有些项目真的很简单，只需要核心元素。我们确实尝试与任意项目分离作斗争，所以按层划分确实很有意义。层由需要在项目，解决方案之间共享的内容或需要作为插件/扩展的内容定义。

有趣的是，很多人在这里不考虑DRY。在我的生命中，发生过几次开发人员创建了因此而无法构建的目录结构。将项目名称保留在解决方案和项目目录之外！

所以这是我的方式：

{drive}:\{customer}\{apps|libs|tools}\{project}
  - cer
  - res
  - src
   - Common
   - Data
   - UI
   - Logic
   - Logic._Tests  

在设计应用程序时，我总是将其视为具有某些依赖关系的模块。当我想到一个设计时，便使用自下而上的策略来开发它。我开发每个模块，然后让它们一起工作。

好吧，这些模块是我的解决方案下的项目（通常是类库）。每个模块都有一个不同的名称空间和自己的设计（包含类等）。

这些模块之一是GUI（图形用户界面）。

我还始终使用修订控制工具来跟踪每个项目中的更改。我建议吉特。它是开源的，分布式的并且可以免费使用。

每次我开始一个新项目时，我都会得到关于它应该做什么的广泛说明。有了这些输入，就可以为我提供上下文，这对我有所帮助，因此，我继续思考最好的（或最合适的）方法来实现项目目标。在这一点上，我开始考虑可以使用哪些设计模式来提供预期的解决方案。考虑到我将为该项目采用的设计模式，这是我开始组织该项目的地方。

几个例子：

1. 如果项目仅涉及建立输入数据屏幕。我很可能会使用MVC模式。
2. 如果将项目用作最支持多种平台的重型UI，则MVVM设计模式将很有帮助。

请记住，每一项都会迫使您以特定方式组织项目。

这是给您的一些阅读材料：

.Net设计模式。

设计模式。

面向对象设计。

希望这可以帮助。