域名服务的最佳设计

本文关键字：最佳 域名服务 | 更新日期: 2023-09-27 18:18:48

我有一个关于我的域名服务的最佳设计的问题。这个用例是基于用户选择的条件创建一些实体。

将使用此服务的应用程序的工作流程:

  1. 用户选择一些条件(如日期和其他数据)
    2. 他得到了实体的"命题"列表。他可以选择所有的，或者只有一些。
  2. 创建实体

域名服务的最佳设计是什么?我有两个想法:

解决方案1 

interface IMyDomainService
{
    IEnumerable<EntityProposition> GetEntitiesPropositions(Conditions conditions);
    void CreateEntities(Conditions conditions);
}

在这种情况下，我可能会在服务上有一些私有方法，这些方法将被两者使用。EntityProposition类基本上是视图中显示内容的1:1。类中有一些数据不是实体本身的一部分。

解决方案2 

interface IMyDomainService
{
    IEnumerable<EntitiyData> GetDataForEntities(Conditions conditions);
    void CreateEntities(IEnumerable<EntityData> entities);
}

解决方案1中的私有方法现在在接口中公开了。EnityData类保存与创建实体本身和显示视图相关的实体的所有数据。

添加一些上下文:该服务现在由ASP直接使用。。NET MVC控制器。在我看来，如果我采用解决方案#2，我将不得不创建一些额外的应用程序服务，因此它将封装获取数据和创建实体的逻辑。

编辑1

我将从不同的角度问这个问题:我的控制器应该是这样的吗? 

public ActionResult GetPropositions(Condtidions condtitions)
{
    var entitiyData= service.GetEntityData(conditions);
    return Json(entitiyData.ToViewModel());
}
public void CreateEntities(Conditions conditions)
{
    var entitiyData= service.GetEntityData(conditions);
    service.CreateEntities(entitiyData);
}

或:

public ActionResult GetPropositions(Condtidions condtitions)
{
    var propositions = service.GetPropositons(conditions);
    return Json(propositions.ToViewModel());
}
public void CreateEntities(Conditions conditions)
{
    service.CreateEntities(conditions);
}

当然，这是一个简化的例子，只是为了说明我的观点。

编辑2

作为后续:首先我采用了解决方案#2，但后来我的需求改变了，我不得不回到解决方案#1。背后的原因是，在生成命题后，用户可以选择很少的命题，但在相同的范围(条件)内。

域名服务的最佳设计

最常见的情况是什么?创建多个实体还是创建一个实体?

我也不会在方法名中使用Entites，很明显，服务与实体一起工作。

对我来说，这个名字听起来就像你只是用服务包装了一个存储库。这是一个大禁忌。DDD中的服务是域实体的扩展，用于封装在同一业务用例中必须使用两个或更多实体的逻辑。

如果你只需要获取一个实体，修改它并保存它，你应该直接使用存储库(不需要抽象一个抽象)

interface IMyDomainRepository
{
    IEnumerable<EntitiyData> GetData(Conditions conditions);
    void Create(IEnumerable<EntityData> entities);
}
相关文章：