如何组织项目结构

Posted 2020-11-24 tpf386

 参考：How do you organize your projects? [closed]

 地址：https://softwareengineering.stackexchange.com/questions/40394/how-do-you-organize-your-projects

 

 

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

 

一旦我对他们要求的内容有了基本的了解，我就会确定他们要操作的核心数据是什么，并开始为这些数据进行基本的数据库布局。然后，我开始问一些问题，以定义围绕数据的业务规则。

 

通过独立地从两端开始，我能够以一种将两端结合在一起的方式来规划一个项目。我总是试着把设计尽可能的分开，然后再把它们融合在一起，但是当我继续前进的时候，要记住每个设计的要求。

 

一旦我对问题的每一端都有了一个很好的理解，我就开始为解决问题而设计项目的结构。

 

创建项目解决方案的基本布局后，我将查看项目的功能，并根据所做工作的类型设置所使用的名称空间的基本集合。这可能是诸如帐户，购物车，调查等。

 

下面是我通常从这里开始的基本解决方案布局。当项目得到更好的定义时，我会对其进行细化，以满足每个项目的特定需求。有些领域可能与其他领域合并，我可以在需要时增加一些特殊的领域。

SolutionName

.ProjectNameDocuments
　　对于大型项目，需要与其一起保存某些文档。为此，我实际上在解决方案中创建了一个单独的项目或文件夹来保存它们。
  
.ProjectNameUnitTest
　　单元测试始终取决于项目-有时它确实是
     　　基本功能，可以捕获极端情况，有时会设置为完整代码
     　　覆盖范围。 我最近将图形化单元测试添加到了军械库。

.ProjectNameInstaller
   有些项目有特定的安装要求，需要在项目级别上处理。
.ProjectNameClassLibrary
   如果需要Web服务、API、DLL等。
.ProjectNameScripts (**Added 2/29/2012**)
   我增加这个是因为我刚刚在我的当前项目中发现了一个需求。该项目包含以下类型的脚本：SQL(表、pros、视图)、SQL数据更新脚本、VBScripts等。
.ProjectName
    .DataRepository 
       包含基类和数据库通信。有时还保存包含任何SQLProcs或其他特定代码的目录。
    .DataClasses
       包含在项目中使用的基类、结构和枚举。它们可能与数据存储库中的数据相关，但不一定连接到数据存储库中的数据存储库中。
    .Services 
       对数据执行所有CRUD操作，这样就可以更改存储库，而无需重写任何更高级别的代码。
    .Business
      执行任何数据计算或业务级别数据验证，与服务层进行大多数交互。
    .Helpers
      我总是创建一个包含助手类的代码模块。这些可能是对系统项、标准验证工具、正则表达式或自定义项的扩展。
    .UserInterface
       用户界面是用来显示和操作数据的。UI窗体总是按照功能单元命名空间组织，并为共享窗体和自定义控件提供额外的文件夹。

 

------------------------------------

我喜欢把我的项目分成几个层次

这样，管理循环依赖关系就更容易了。例如，我可以保证没有任何项目错误地导入视图项目(层)。我也倾向于把我的层分解成子层。所以我所有的解决方案都有这样的项目清单：

• Product.Core
• Product.Model
• Product.Presenter  控制层
• Product.Persistence  持久层
• Product.UI
• Product.Validation
• Product.Report
• Product.Web

它们是我的应用程序中更大的“构建块”。然后，在每个项目中，我在名称空间中组织得更有逻辑，但变化很大。对于UI，在创建许多表单时，我尝试在空间划分中进行思考，然后为每个“空间”创建名称空间。假设有一堆用户首选项、用户控件和表单，我将为它们提供一个名为UserPreferences的名称空间，等等。

 

-------------------------------------

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

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

希望这对你有用。分离的程度花了我一段时间才弄清楚。

 

-------------------------

总结：

其实什么乱七八糟的分层方式都有了，见得多了以后反而不太在乎项目的分层结构；

最经典的当属三层架构

然后是是四层

然后是多层；

…………