命名静态“服务”的名称以及将其放置在 mvc 解决方案中的位置 [关闭]

Question

我的网站结构如下：

• ProjectName.Core - 实体框架、上下文、迁移、接口、扩展、枚举
• ProjectName.Models - 仅限 DTOS
• ProjectName.Repositories - 仅限存储库
• ProjectName.Services - 通过 ninject 与存储库对话、自动映射器配置实例化的服务
• ProjectName.Tests - 不言自明
• ProjectName.Web.Customer - 客户 mvc 站点
• ProjectName.Web.Admin - 管理 mvc 站点

我的问题：

我应该把静态的“帮助”类放在哪里，比如下面，我应该怎么称呼它们？

• 剃须刀解析器
• 串行器/解串器
• 电子邮件发件人

将它们称为服务并将它们与非静态服务放在一起感觉不对，这对其他开发人员来说并不直观......

Answer 1

我想解决我在您在问题中给出的结构中注意到的一些歧义。通过查看您的结构，我假设您正在尝试实现某种Onion-/Clean-/Hexagonal 架构。

如果您分析上面提出的架构指南，您的核心项目不应该包含任何基础设施问题，例如您的案例中的实体框架。核心本身应该只包含您的业务/领域模型（以及业务规则）和领域服务。

现在让我们想一想：如果您要考虑 EF 或任何其他基础设施问题，Core 的测试会是什么样子？通过测试 Core，您通常会尝试一次测试 一个 东西......所以您不必模拟其余的依赖项。

现在要准确回答您的问题，命名为not easy。我看到一个答案建议您将事物与应用程序的其余部分分开。这本身很好，但我不推荐它，如果你为了一些好的实践而使用很多项目，它可以变成pain。我写这篇文章的一个示例原因是想一下额外的时间来编译您的解决方案，其中包含 3 个额外的项目，用于 3 个不同的事情？

我对组织这些基础设施问题的建议如下：

1. 创建一个名为ProjectName.Infrastructure的项目

   • 将每个所需的 NuGet 包/DLL 引用添加到项目中
   • 在此项目中创建目录来组织您的服务

2. 根据您创建的目录在此处添加/创建服务的实现

   • 确保每个服务都实现一个接口，您将在您的消费者类中注入该接口
   • 作为一个好的建议，根据类名通过命名空间将这些服务分开，例如：ProjectName.Infrastructure.EmailService

3. 最后一部分是通过 NInject 将这些基础设施问题连接在一起

最后的话：我希望你真的不需要这些服务在你写的类级别上是静态的。如果是这样，您仍然可以通过适当的 NInject 绑定范围以这种方式绑定它们。

Answer 2

与其将所有这些不相关的问题混为一谈，不如将其变得更加细化？像这样：

• ProjectName.Infrastructure.Serialization
• ProjectName.Infrastructure.Razor
• ProjectName.Infrastructure.Email

这样语义和结构会更好，并且您可以将功能分开。

Answer 3

它们自己的文件夹或核心中的服务。

我不会为静态助手添加另一个项目。