如何命名静态 "service" 以及将其放置在 mvc 解决方案中的什么位置
What to name a static "service" and where to place it in mvc solution
我的网站结构如下：
- ProjectName.Core - entity framework、上下文、迁移、接口、扩展、枚举
- ProjectName.Models - 仅 DTOS
- ProjectName.Repositories - 仅限存储库
- ProjectName.Services - 通过 ninject 与存储库对话、自动映射器配置
实例化的服务
- ProjectName.Tests - 不言而喻
- ProjectName.Web.Customer - 客户 mvc 站点
- ProjectName.Web.Admin - 管理 mvc 站点
我的问题：
我应该把下面的 static "helper" 类 放在哪里，我应该怎么称呼它们？
- razor 解析器
- serializer/deserializer
- 电子邮件发件人
将它们称为服务并将它们与非静态服务放在一起感觉不对，这对其他开发人员来说不直观...
在自己的文件夹或 Core 中的服务。
我不会只为静态助手添加另一个项目。
与其将所有这些不相关的问题集中在一起，为什么不让它更细化呢？像这样：
- ProjectName.Infrastructure.Serialization
- ProjectName.Infrastructure.Razor
- ProjectName.Infrastructure.Email
这样语义和结构更好，并且您将功能分开。
我想解决我在问题中给出的结构中注意到的一些歧义。通过查看您的结构，我假设您正在尝试实现某种 Onion-/Clean-/Hexagonal 架构。
如果您分析上面提议的架构指南，第一眼就会清楚您的核心项目 不应 包含任何基础设施问题，例如 Entity Framework 在你的情况下。核心本身应该只包含您的 business/domain 模型（以及业务规则）和领域服务。
现在让我们想一想：如果您要考虑 EF 或任何其他基础架构问题，Core 的测试会是什么样子？通过测试 Core，您通常是在尝试一次测试 一个 东西...因此您不必模拟其余的依赖项。
现在准确地回答你的问题，如果你只是为了一些好的做法而使用很多项目，那么命名事物就是 not easy. I see that an answer recommends you to separate things from the rest of your application. Which in itself is good, but I wouldn't recommend it, it can become a pain。我写这篇文章的一个例子是考虑额外的时间用 3 个额外的项目为 3 个不同的东西编译你的解决方案？
我对组织这些基础设施问题的建议如下：
创建名为 ProjectName.Infrastructure
的项目
- 将每个必需的 NuGet packages/DLL 引用添加到项目
- 在此项目中创建目录以组织您的服务
Add/create 您在此处创建的每个目录的服务实现
- 确保每个服务实现一个接口，您将在您的消费者中注入该接口classes
- 作为一个好建议，根据 class 名称通过名称空间将这些服务分开，例如：
ProjectName.Infrastructure.EmailService
最后一部分是通过 NInject
最后的话：我希望您真的不需要这些服务像您写的那样在 class 级别保持静态。如果是这样，您仍然可以通过适当的 NInject 绑定范围以这种方式绑定它们。
我的网站结构如下：
- ProjectName.Core - entity framework、上下文、迁移、接口、扩展、枚举
- ProjectName.Models - 仅 DTOS
- ProjectName.Repositories - 仅限存储库
- ProjectName.Services - 通过 ninject 与存储库对话、自动映射器配置 实例化的服务
- ProjectName.Tests - 不言而喻
- ProjectName.Web.Customer - 客户 mvc 站点
- ProjectName.Web.Admin - 管理 mvc 站点
我的问题：
我应该把下面的 static "helper" 类 放在哪里，我应该怎么称呼它们？
- razor 解析器
- serializer/deserializer
- 电子邮件发件人
将它们称为服务并将它们与非静态服务放在一起感觉不对，这对其他开发人员来说不直观...
在自己的文件夹或 Core 中的服务。
我不会只为静态助手添加另一个项目。
与其将所有这些不相关的问题集中在一起，为什么不让它更细化呢？像这样：
- ProjectName.Infrastructure.Serialization
- ProjectName.Infrastructure.Razor
- ProjectName.Infrastructure.Email
这样语义和结构更好，并且您将功能分开。
我想解决我在问题中给出的结构中注意到的一些歧义。通过查看您的结构，我假设您正在尝试实现某种 Onion-/Clean-/Hexagonal 架构。
如果您分析上面提议的架构指南，第一眼就会清楚您的核心项目 不应 包含任何基础设施问题，例如 Entity Framework 在你的情况下。核心本身应该只包含您的 business/domain 模型（以及业务规则）和领域服务。
现在让我们想一想：如果您要考虑 EF 或任何其他基础架构问题，Core 的测试会是什么样子？通过测试 Core，您通常是在尝试一次测试 一个 东西...因此您不必模拟其余的依赖项。
现在准确地回答你的问题，如果你只是为了一些好的做法而使用很多项目，那么命名事物就是 not easy. I see that an answer recommends you to separate things from the rest of your application. Which in itself is good, but I wouldn't recommend it, it can become a pain。我写这篇文章的一个例子是考虑额外的时间用 3 个额外的项目为 3 个不同的东西编译你的解决方案？
我对组织这些基础设施问题的建议如下：
创建名为
的项目ProjectName.Infrastructure- 将每个必需的 NuGet packages/DLL 引用添加到项目
- 在此项目中创建目录以组织您的服务
Add/create 您在此处创建的每个目录的服务实现
- 确保每个服务实现一个接口，您将在您的消费者中注入该接口classes
- 作为一个好建议，根据 class 名称通过名称空间将这些服务分开，例如：
ProjectName.Infrastructure.EmailService
最后一部分是通过 NInject
将这些基础设施问题联系在一起
最后的话：我希望您真的不需要这些服务像您写的那样在 class 级别保持静态。如果是这样，您仍然可以通过适当的 NInject 绑定范围以这种方式绑定它们。