我的网站结构如下：
我的问题：
我应该把静态“帮助”类放在哪里，比如下面，我应该怎么称呼它们？
将它们称为服务并将它们与非静态服务放在一起感觉是错误的，这对其他开发人员来说并不直观......
我想解决我在您在问题中给出的结构中注意到的一些歧义。通过查看您的结构，我假设您正在尝试实现某种Onion -/ Clean -/ Hexagonal架构。
如果您分析上面提出的架构指南，第一眼就会清楚您的核心项目不应该包含任何基础设施问题，例如您的案例中的实体框架。核心本身应该只包含您的业务/领域模型（沿着业务规则）和领域服务。
现在让我们想一想：如果您打算将 EF 或任何其他基础设施问题纳入图片，Core 的测试会是什么样子？通过测试 Core，您通常会尝试一次测试一件事……因此您不必模拟其余的依赖项。
现在要准确回答您的问题，命名事物并不容易。我看到一个答案建议您将事物与应用程序的其余部分分开。这本身很好，但我不推荐它，如果你只是为了一些好的实践而使用很多项目，这可能会变得很痛苦。我写这篇文章的一个示例原因是想想额外的时间来编译你的解决方案，其中包含 3 个额外的项目，用于 3 个不同的事情？
我对组织这些基础设施问题的建议如下：
创建一个名为ProjectName.Infrastructure
根据您创建的目录在此处添加/创建服务的实现
ProjectName.Infrastructure.EmailService最后一部分是通过 NInject 将这些基础设施问题连接在一起
最后的话：我希望你真的不需要这些服务在你写的类级别上是静态的。如果是这样，您仍然可以通过适当的 NInject 绑定范围以这种方式绑定它们。
与其将所有这些不相关的问题混为一谈，不如让它更细化呢？像这样：
这样语义和结构会更好，并且您可以将功能分开。
服务在自己的文件夹或核心里面。
我不会为静态助手添加另一个项目。