类别。 。

Question

好的，所以我一直试图将每个人的一个类放在一些根文件夹中，或者：

UI
BusinessLogic
数据访问
的BusinessObjects
接口

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

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

2. 活动Arg课程？

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

一个。

projectX创建
--Subsystem1
----的BusinessObjects
----数据访问
----的BusinessObjects
--Subsystem2
----的BusinessObjects
----数据访问
---- BusinessObjects

或

projectX创建
--BusienssLogic
---- Subsystem1BL
---- Subsystem2BL
--DataAccess
---- Subsystem1DA
---- Subsystem2DA
--BusinessObjects
---- Subsystem1BO
---- Subsystem2BO

或

projectX创建
--BusinessLogic
--DataAccess
--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

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

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

抱歉，我错过了C＃标签。良好的.NET项目示例已涵盖在here和here之前。

Answer 4

这主要是个人品味。

我同意Brian Genisio said关于在哪里放置EventArg类等：如果你只使用它们一次，把它们放在你使用它们的同一个文件中。对于一般的类/文件，我总是有一个'General'文件夹（方便！！ - ））

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

Answer 5

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