Question

以用户的简单示例为例，根据我的经验，我发现执行的检查/逻辑总是略有不同，具体取决于您是创建还是更新用户（此问题扩展到更新其他域）实体也是）。当您添加具有基本原理的自由度喷洒时，代码很快会被意外破坏 “只需在更新时检查用户”和“哦，只需执行此检查，逻辑，在创建用户时插入”

所有这一切的总和是一个巨大的代码庞然大物，这是一个血腥的眼睛看。我认为完全重构/分离这个逻辑只是常识。或者我疯了。

谢谢，

Answer 1

嗯，基本上有两种模式可供选择：

完全分开添加和更新的案例。
制作一个处理添加和更新的案例。

具有单独案例的优点是代码变得更清晰，缺点是您重复了大部分代码。使用单个案例来避免重复代码也意味着代码变得更加复杂。

尝试创建介于两者之间的东西最有可能最终导致两种模式的缺点。

Answer 2

我会在这种情况下使用Template Pattern。基本上，您可以将所有重复的代码放在基类中，并让继承的类实现细节。一个简单的伪代码示例如下所示：

IRep

class IRep
{
   void Add(object a);
   void Remove(object a);
}

BaseRep

abstract class BaseRep : IRep
{
    void Add(object a)
    {
       if(OkToAdd(a))
       {
          // Common Rep code here
       }
    }

    void Remove(object a)
    {
       if(OkToRemove(b))
       {
          // Common Rep code here
       }
    }

    abstract bool OkToAdd(object a);
    abstract bool OkToRemove(object a);
}

MyRep1

class MyRep1 : BaseRep
{
    bool OkToAdd(object a)
    {
       // Add specific checks here for MyRep1
    }

    bool OkToRemove(object a)
    {
       // Add specific checks here for MyRep1
    }
}

MyRep2

class MyRep2 : BaseRep
{
    bool OkToAdd(object a)
    {
       // Add specific checks here for MyRep2
    }

    bool OkToRemove(object a)
    {
       // Add specific checks here for MyRep2
    }
}

Answer 3

我喜欢将它们完全分开。尽管这可能看起来像代码重复，但它允许在将来独立地发展这些操作。并且它们可以彼此完全不同：在创建时，可能存在一些不需要的字段，甚至不允许设置，并且在每种情况下可能存在许多不同的规则要检查。如果你完全将这些行为分开，那么你就可以完全自由地发展它们。

Answer 4

我发现总有一个略有不同的一块检查/逻辑执行取决于无论您是创建还是更新用户

当然涉及不同的逻辑。

创建实体并对实体进行更改是两种截然不同的操作。不要试图让它们做同样的操作。

Answer 5

好的，所以我在职业生涯中待了几年，现在我在设计/理解软件时已经意识到了许多方法。

我所描述的似乎是贫血领域模型和交易脚本的症状。如果存储在用于持久性的方法/操作中的业务规则很快就会变得纠结，如果在存储库或持久性存储上进行创建/ upsert / update操作。

在这种方法中，意图和业务规则很快就会丢失。

减轻这种情况的一种方法是依靠DDD方法并仔细建模行为，以便只更改相关状态然后保持（很可能是在该聚合中的聚合或实体/值对象）。这有助于确保通过明确指示正在更改状态的操作来存在可审计的故事。例如：

Customer.AddUsername(string username)

此方法将更新用户名，其范围是在操作中使用业务规则。

是否有任何好的模式/原则可以分离出创建和更新逻辑

5 个答案: