您是否有任何特殊的组织项目风格？
例如，目前我正在为玻利维亚的几所学校创建项目，这是我的组织方式：
TutoMentor (Solution)
TutoMentor.UI (Winforms project)
TutoMentor.Data (Class library project)
您如何精确地组织项目？您是否有自己组织并为之自豪的事例？您可以共享“解决方案”窗格的屏幕截图吗？
在我的应用程序的UI区域中，我很难确定一个好的架构来组织不同的表单及其所属位置。
编辑：
如何在.UI项目中组织不同的形式？我应该在哪里/如何分组其他形式？将它们全部置于项目的根目录是一个坏主意。
#1 楼
在设计项目和布局体系结构时，我从两个方向开始。首先，我查看正在设计的项目并确定需要解决的商务问题。我看看将要使用它的人，并从一个粗糙的UI设计开始。在这一点上，我将忽略数据，而只是查看用户的要求以及谁将使用它。一旦我对他们的要求有了基本的了解，就可以确定将要处理的核心数据是什么，并开始对该数据进行基本的数据库布局。然后，我开始提出问题，以定义围绕数据的业务规则。
通过独立地从两端开始，我可以以将两端融合在一起的方式布置项目。在将它们融合在一起之前，我总是尽力将它们分开尽可能长的时间，但是在前进的过程中请牢记每个设计的要求。这个问题我开始列出将要解决该问题的项目结构。
一旦创建了项目解决方案的基本布局，我就会查看项目的功能并设置一组基本的名称空间，这些名称空间将根据要完成的工作类型使用。这可能是诸如帐户，购物车，调查等之类的内容。
这是我始终以的基本解决方案布局。随着项目的定义得到更好的定义，我将其进行改进以满足每个项目的特定需求。有些区域可能会与其他区域合并，我可能会根据需要添加一些特殊区域。
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.
评论
到目前为止最好的答案！
–塞尔吉奥
2011年2月4日在16:01
享受赏金，您的回答极大地帮助了我。
–塞尔吉奥
2011年2月5日在23:01
@Amy他们都是项目吗？还是仅仅是顶级物品？我对.Net相当陌生，无法确定是项目还是项目的子文件夹。
–卡森·迈尔斯（Carson Myers）
2011年7月7日在4:15
@Carson Myers，每个顶层项目都是项目，第二层项目是项目中的文件夹。某些顶级项目是编译为dll的项目，其他项目可以根据需要引用这些项目。
–艾米·帕特森（Amy Patterson）
2011年7月7日在14:30
@Amy我非常喜欢您的回答，非常详细的解释。但是在某些示例中，我看到人们将DataRepository，DataClasses，Services，Business等划分为不同的项目，而不是同一项目中的不同文件夹。您对此有何看法？两种选择之间的优点/缺点是什么？谢谢！
– emzero
2012年4月4日19:20在
#2 楼
我喜欢将项目分成多个层，这样可以更轻松地管理循环依赖性。例如，我可以保证没有任何项目会错误地导入View项目（图层）。我也倾向于将我的图层细分为子图层。因此，我所有的解决方案都有这样的项目列表：
Product.Core
Product.Model
Product.Presenter
Product.Persistence
Product.UI
Product.Validation
Product.Report
Product.Web
它们是我应用程序中更大的“构建基块”。然后，在每个项目中，我都更合理地在名称空间中进行组织，但变化很大。对于UI，当创建大量表单时，我尝试以空间分隔的方式思考，然后为每个“空间”创建名称空间。假设有很多用户首选项，用户控件和表单，我将为它们提供一个名为UserPreferences的命名空间，以此类推。
评论
关于什么：产品-核心-模型-演示者-持久性-UI-验证-报告-Web
–丹尼尔·费希尔（Daniel Fisher）lennybacon
2014年7月10日在8:34
我觉得Core很危险，因为它导致了整体代码设计，其中大多数逻辑可能会或可能不会出现在Core中。例如：听起来不像是模型，演示者，持久性，UI，验证，报告，Web的逻辑自然会被扔到Core中。
– Yeo
2015年11月1日在11:38
@Yeo这可以起到两方面的作用，要么将您的Core项目变成一片垃圾，要么使您免于拥有包含数百个项目的解决方案。做出该决定是开发人员的责任，没有任何项目结构可以使不良编码人员免于做不良事情。
– Alex
2015年11月6日在16:58
@Prokurors是的，通常在Product.Core内部是我放置系统“核心”业务逻辑的地方。 “ ui业务逻辑”应放在Product.Presenter中。例如，如果您的系统决定在加载某些数据时必须禁用按钮，那就是我所说的“ ui业务逻辑”，并将其放入演示器中。 “核心业务逻辑”与您的核心模型（或域模型）直接相关。消息传递系统可能会决定最大字符数为140个字符，这是属于您业务核心的逻辑。
– Alex
16 Mar 27 '16 at 13:59
产品与UI或Web有何不同？
–多巴特拉曼
16-9-28在20:22
#3 楼
组织项目就像您说的那样，我通常会尝试按名称空间划分项目。应用程序或组件的每一层都是其自己的项目。关于如何决定如何将解决方案分解为项目，我将重点放在这些项目的可重用性和依赖性上。我在考虑我团队的其他成员将如何使用该项目，如果我们在将来创建的其他项目可能会受益于使用系统的某些组件。例如，有时，只有具有一整套框架（电子邮件，日志记录等）的项目就足够了：
MyCompany.Frameworks
其他时候，我可能想将框架分解为几部分，所以可以将它们分别导入：
MyCompany.Frameworks.Networking
MyCompany.Frameworks.Logging
MyCompany.Frameworks.SomeLOBFramework
组织表单
在UI项目下组织表单确实会随着您的项目而变扩展。
小-一个简单的Forms文件夹就可以满足一个非常小的项目。有时，您可以像命名空间一样对结构进行过度设计，并使事情变得比其复杂得多。
中到大-在这里，我通常开始将表格分为功能区域。如果我的应用程序的一部分具有3个用于管理用户的表格，而有些则可以跟踪足球比赛和得分，那么我将拥有一个表格>用户区域和表格>游戏区域或类似内容。这实际上取决于项目的其余部分，我有多少种形式以及我如何细分它。
请记住，在一天结束时，名称空间和文件夹仅在这里提供帮助您可以更快地组织和查找事物。
确实，这取决于您的团队，您的项目以及对您而言更轻松的事情。我建议通常，您为系统的每个层/组件创建单独的项目，但是总是有例外。
有关系统体系结构的指南，请参见Microsoft的Patterns and Practices网站。
#4 楼
当我用.NET编写代码时，很明显有相关功能的集群。每个都可能具有相同的一些子集。我喜欢从身体上划分主要群体-每个VS项目一个。然后，我在逻辑上使用程序集进一步细分。按照这种模式，我当前的项目之一是这样的： >Wadmt.Data.MySql
Wadmt.Data.SqlServer
Wadmt.Data.Oracle
Wadmt.Domain
Wadmt.Services
Wadmt.Tests
Wadmt.Tests.Domain
Wadmt.Tests.Domain
Wadmt.Tests.Services
Wadmt.Tests.Integration
Wadmt.Web
希望对您有用。分离级别花了我一些时间来弄清楚。
评论
我会减少“ Wadmt”。保持文件系统干燥。在控制台上工作时，这很有帮助...
–丹尼尔·费希尔（Daniel Fisher）lennybacon
2014年7月10日在8:34
#5 楼
有一个计划来组织您的解决方案是很好的，并且有几种方法可以实现。我们具有在多个项目之间共享的某些功能，这也为我们的用户提供了一致性。项目组织确实取决于我们在做什么。它的核心是：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)
必要时可以添加其他子项目。正如我所说，这实际上取决于项目。有些项目真的很简单，只需要核心元素。我们确实尝试与任意项目分离作斗争，所以按层划分确实很有意义。这些层由需要在项目，解决方案之间共享的内容或需要作为插件/扩展的内容定义。
评论
AutomationTests意味着单元和集成测试是手动完成的。如果不阅读评论，还不清楚它是什么意思。
–元预算
20年5月9日在8:21
自动化和集成测试之外的应用程序测试可以是自动的或手动的。我们主要进行自动回归测试，但仍有两个领域仍然是手动的。这使我们能够抓住面向用户的功能意外中断的时间。
–贝琳·洛里奇（Berin Loritsch）
20年5月9日在16:22
#6 楼
有趣的是，很多人在这里不考虑DRY。在我一生中发生过几次，开发人员创建的目录结构因此而无法构建。将项目名称保留在解决方案和项目目录之外！所以这是我的方法：
{drive}:\{customer}\{apps|libs|tools}\{project}
- cer
- res
- src
- Common
- Data
- UI
- Logic
- Logic._Tests
评论
什么干？缩写的东西吗？
– Pithikos
2014年8月21日在15:47
@Pithikos这是不重复自己的首字母缩写
–Pero P.
2014-09-25 18:51
什么是逻辑？ Common文件夹中也没有逻辑吗？
–多巴特拉曼
16-09-28在20:24
我将可重复使用的内容放入了Common。有人可能还会说Framework或Core ...
–丹尼尔·费舍（Daniel Fisher）莱尼·培根
16-09-30在19:57
cer是什么？为什么_Tests之前有下划线？为什么小写和大写混合（cer，res； Common；数据）？我同意应该从项目名称中排除项目名称和公司名称，因为这是多余的，但是您列出的这种结构不是自我解释的，它带来的问题多于清晰度。
–元预算
20年5月9日在8:25
#7 楼
在设计应用程序时，我总是将其视为具有某些依赖关系的模块。当我想到一个设计时，便使用自下而上的策略进行开发。我开发了每个模块，然后使它们一起工作。好，那些模块是我的解决方案下的项目（通常是类库）。每个模块都有一个不同的命名空间和自己的设计（包含类等）。
其中一个模块是GUI（图形用户界面）。
我也经常使用版本控制工具可跟踪每个项目中的更改。我建议吉特。它是开源的，分布式的并且可以免费使用。
#8 楼
每次我开始一个新项目时，我都会得到关于它应该做什么的广泛说明。有了这些输入，就可以为我提供上下文，这对我有所帮助，因此，我继续思考最好的（或最合适的）方法来实现项目目标。此时，我开始思考哪种设计模式可以帮助我提供预期的解决方案。考虑到我将为该项目采用的设计模式，这是我开始组织该项目的地方。
两个示例：
如果该项目仅指建立输入数据屏幕。很可能我会使用MVC模式。
如果要将该项目用作最支持多种平台的重型UI，则MVVM设计模式会有所帮助。
都会迫使您以特定方式组织项目。
为您提供一些参考资料：
.Net设计模式。 />设计模式。
面向对象的设计。
希望有帮助。
评论
哇，有450赏金！？@muntoo：是的，我对一些很棒的答案很感兴趣。 :)
应该明确指出您询问C＃。我个人从来没有看到这些标签。
有关.Net存储库的典型结构，请参见gist.github.com/davidfowl/ed7564297c61fe9ab814
与往常一样，由于XYZ原因，许多好问题被关闭。我们可能还有很多其他好的答案。