在哪里存储类文件

本文关键字：文件 存储 在哪里 | 更新日期: 2023-09-27 18:10:42

我通常为我的项目创建一个单独的类库，然后将其分解到文件夹中

Services
 -all my .cs files that are service(business logic)
Data
 - Mapping 
   - nhibernate mapping files
Domain
  - domain files

我还创建了其他文件夹比如我在做foursquare的东西所以所有的class files都在一个名为"foursquare"的文件夹

但是我不知道把one off class files放在哪里。例如，我有"HtmlWhiteList" class，这是唯一一种白名单。

我不认为它应该有自己的文件夹，因为它只是一个文件，但同时我也不喜欢把它放在根目录下。

有什么建议放在哪里，不值得自己的文件夹类文件?

在哪里存储类文件

作为一般的经验法则，我将新的类文件放在调用它的另一个类的根目录中。如果我有5个或更多相似的类，我会创建一个文件夹并把它们放在同一级别的文件夹

有时候我创建了一个"Utilities"文件夹来存放其他东西。事情通常会转移到那里，一旦他们有了其他类似的类，就会转移到其他地方……但有时它们会停留在那里。当然，这是非常主观的个人偏好。

我会把它和调用它的代码的类放在一起。否则就给它自己的文件夹，不能保证它永远是唯一属于那里的类。不过，我认为这更像是一个意见问题，而不是一个有具体答案的问题。

我们不再使用这种结构。最后出现了"枚举"、"接口"、"实体"等文件夹。当你为一个特性编写代码时，比如说"订单"特性，你需要所有的命名空间来获得你需要的类型，因为与订单相关的类分布在各处。因此，我们将其改为面向功能的结构，使用诸如"订单"、"文章"、"用户"等命名空间。

.Net命名指南中有一个建议，命名空间的名称:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

哪个特性属于HtmlWhiteList ?安全吗?去客户端?我不能告诉你，因为我不知道它是什么。

如果你不知道它做什么或谁使用它，因此你不知道把它放在哪里，或者它所做的事情微不足道，因此不值得有一个地方，那么完全删除它。

如果你认为它不应该被删除，那么它应该有一个位置。

如果它很少使用，那么你应该确切地知道谁在使用它，它对他们有什么影响-然后你应该立即知道把它放在哪里:在他们附近的地方。

如果没有这样的地方，创造它并与它共存。随着项目的发展，当一个更好的地方出现时，你可以随时把它搬到那里。看看你的项目结构，如果它是真正的实用程序，那么Service不是用于"业务逻辑"，而是用于服务和实用程序。如果您将您的BL建模为"服务"，那么这是您的选择，但这并不意味着所有的服务都是BL。

如果这个类有很多分散的用户，以至于你无法决定谁更重要或更相关，那么就把它创建为一个新的模块/库/文件夹，因为它被大量使用，实际上很重要。

相关文章：