1

好的，所以我一直在尝试将每个人的课程之一放在某个根文件夹中，或者：

UI
BusinessLogic
DataAccess
BusinessObjects
接口

我还有一些我似乎不太好斗的地方，所以我正在寻找建议

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

  2. 事件 Arg 类？

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

一种。

ProjectX
--Subsystem1
----BusinessObjects
----DataAccess
----BusinessObjects
--Subsystem2
----BusinessObjects
----DataAccess
----BusinessObjects

或者

ProjectX
--BusienssLogic
----Subsystem1BL
----Subsystem2BL
--DataAccess
----Subsystem1DA
---- Subsystem2DA
--BusinessObjects ----
Subsystem1BO
----Subsystem2BO

或者

ProjectX
--BusinessLogic
--DataAccess --BusinessObjects
（
每个功能子系统没有子目录）

4

5 回答 5

2

我尝试将我的程序集名称与其命名空间对齐，并使用 .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

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

[解决方案]
--[Company].Core.Data
----[Adapters]
------(Adapters files)
----[Caching]
------(Caching files)
---- [转换器]
------（转换器文件）

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

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

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

于 2008-11-23T18:07:00.610 回答
0

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

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

尽管我喜欢良好的组织，但它可能会变得过于肛门。

于 2008-11-23T14:41:05.627 回答
0

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

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

抱歉，我错过了 C# 标签。优秀的 .NET 项目示例已在此处和此处之前介绍过。

于 2008-11-23T14:42:04.797 回答
0

这主要是个人口味。

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

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

于 2008-11-23T14:53:01.407 回答
0

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

于 2008-11-23T14:53:55.537 回答