1

我的网站结构如下:

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

我的问题:

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

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

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

4

3 回答 3

1

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

如果您分析上面提出的架构指南,第一眼就会清楚您的核心项目不应该包含任何基础设施问题,例如您的案例中的实体框架。核心本身应该只包含您的业务/领域模型(沿着业务规则)和领域服务。

现在让我们想一想:如果您打算将 EF 或任何其他基础设施问题纳入图片,Core 的测试会是什么样子?通过测试 Core,您通常会尝试一次测试件事……因此您不必模拟其余的依赖项。

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

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

  1. 创建一个名为ProjectName.Infrastructure

    • 将每个所需的 NuGet 包/DLL 引用添加到项目中
    • 在这个项目中创建目录来组织你的服务
  2. 根据您创建的目录在此处添加/创建服务的实现

    • 确保每个服务都实现了一个接口,您将在您的消费者类中注入该接口
    • 作为一个好的建议,根据类名通过命名空间将这些服务分开,例如:ProjectName.Infrastructure.EmailService
  3. 最后一部分是通过 NInject 将这些基础设施问题连接在一起

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

于 2016-06-14T11:33:34.377 回答
0

与其将所有这些不相关的问题混为一谈,不如让它更细化呢?像这样:

  • ProjectName.Infrastructure.Serialization
  • ProjectName.Infrastructure.Razor
  • 项目名称.基础设施.电子邮件

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

于 2016-06-13T11:43:03.470 回答
-1

服务在自己的文件夹或核心里面。

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

于 2016-06-13T11:25:23.303 回答