类分桶。 .

Question

好的，所以我一直在尝试将我的每个班级都放在某个根文件夹中：

用户界面
业务逻辑
数据存取
业务对象
接口

我还有一些我似乎无法很好地存储的地方，所以我正在寻找建议

1. 一个 Cache 类，它维护一个私有字典并允许基于某些特定键对对象进行不同的访问

2. 事件参数类？

此外，在一个项目下，我现在开始拥有具有所有 3 个（数据访问、业务对象、业务逻辑）的子系统。我应该如何分解文件夹结构？

A.

ProjectX
--子系统1
----业务对象
----数据访问
----业务对象
--子系统2
----业务对象
----数据访问
----业务对象

或

ProjectX
--商业逻辑
----子系统1BL
----子系统2BL
--数据访问
----子系统1DA
----子系统2DA
--BusinessObjects
----子系统1BO
----子系统2BO

或

ProjectX
--业务逻辑
--数据访问
--BusinessObjects
（每个功能子系统没有子目录）

Answer 1

我尝试将我的程序集名称与其命名空间对齐，并使用 .NET Framework 本身作为指导。我坚信使用驱动文件夹结构的命名空间结构可以使代码库更易于维护。

例如，我有一个缓存提供程序，它是我们使用的全球开发人员框架的一部分。它位于类似于以下内容的命名空间中：

[公司].Core.Data.Caching

我还有其他与数据相关的功能，这些功能在逻辑上也属于数据功能，因此缓存具有适配器、转换器和生成器等兄弟。所以，假设我们有以下命名空间：

[公司].Core.Data.Adapters
[公司].Core.Data.Converters
[公司].Core.Data.Caching
[公司].Core.Data.Generators

这些相关的命名空间存在于一个名为 [Company].Core.Data 的程序集中，该程序集也是项目名称。遵循这种结构，在解决方案中查找内容变得非常简单。说到结构，现在我们回到它们在磁盘上的存储方式。

项目名称是根文件夹名称。这假设我的源代码管理文件夹，即本地计算机上的“C:\Source Control”：

C:\Source Control\Core[Company].Core.Data\
C:\Source Control\Core[Company].Core.Data\Adapters
C:\Source Control\Core[Company].Core.Data\Caching
C:\Source Control\Core[Company].Core.Data\Converters
C:\Source Control\Core[Company].Core.Data\Generators

所以，作为一个层次结构，它看起来像：

[解决方案]
--[公司].Core.Data
----[适配器]
------（适配器文件）
----[缓存]
------（缓存文件）
----[转换器]
------（转换器文件）

我将所有项目放在同一级别，并根据文件夹改变子命名空间。这样命名空间和物理结构很容易协调。困难的部分是找到平衡。您不希望拥有大量较小的程序集，因此我通常会将它们分组在更高的级别，并最终在它趋于变得太大或子命名空间比其他部分更频繁地更改时对其进行重构.

我多年来一直这样做，它不仅对我自己，而且对我的开发人员来说都非常舒适。

至于你的 EventArgs 问题，我同意我通常每个文件做一个类的共识，但如果是单一使用，我会例外地将 EventArgs 类与另一个类一起放置。对于多用途，我将它们放在程序集的最高逻辑点，允许命名空间结构绑定我的范围。

Answer 2

我通常喜欢坚持 1 个类，1 个文件的规则，但对于 EventArgs，我实际上喜欢在定义委托或事件的同一个文件中声明它们。除非，args 被多个类层次结构使用，这在我身上并不经常发生。

至于缓存，我会放在它支持的类的文件夹中。

尽管我很喜欢良好的组织，但人们可能会对此感到厌烦。

Answer 3

这主要是个人喜好。

我同意 Brian Genisio said 关于在何处放置 EventArg 类等的意见：如果您只使用一次，请将它们放在使用它们的同一个文件中。对于通用类/文件，我总是有一个“通用”文件夹（多么方便！;-)）

关于文件夹结构：我会选择第二个，那个是 3 层，并保持子系统分开。双赢！

Answer 4

我只想对名称添加评论。 我觉得商业这个词会导致误用。我们这样做了，现在我们不知道它是关于什么的：域逻辑或服务层。 我会建议像这样的名字 领域。 Domain.Impl（将接口与 Impl 分开） 然后是服务……如果您使用的是 ORM，可能还有持久性……如果您使用不同的方法，它可能会有所不同，但老实说，我对 BusinessLogic、DataAccess 和 BusinessObjects 的名称感到困惑。 我不明白什么是什么。 BusinessObjects 应该包含业务逻辑，逻辑？还是他们只是 DTO？那为什么他们在与 DataAccess 不同的项目中呢？

Answer 5

没有一种正确的方法可以做到这一点。

下载一些使用与您的项目类似的技术的开源项目，并从中汲取您的想法。

抱歉，我错过了 C# 标签。在here 和here 之前已经介绍了好的.NET 项目示例。