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

Question

以用户的简单示例为例，根据我的经验，我发现根据您是创建还是更新用户，执行的检查/逻辑总是略有不同（此问题也扩展到更新其他域实体） 。当您添加自由的洒水和基本原理时，代码很快就会变得像意大利面条一样 “只需在更新用户时对用户进行此检查”和“哦，只需在创建用户时执行此检查，逻辑，插入”

所有这些的总和就是一个庞大的代码庞然大物，看起来非常碍眼。我想完全重构/分离这个逻辑只是常识。或者我疯了。

谢谢，

Answer 1

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

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 2

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

Answer 3

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

当然涉及不同的逻辑。

创建实体和更改实体是两种截然不同的操作。不要试图让它们执行相同的操作。

Answer 4

好吧，我的职业生涯又过去了几年，现在我已经了解了设计/理解软件时的多种方法。

我所描述的似乎是领域模型和事务脚本贫乏的症状。如果硬塞进存储库或针对持久性存储的创建/更新插入/更新操作，则埋藏在用于持久性的方法/操作中的业务规则很快就会变得混乱。

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

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

Customer.AddUsername(string username)

此方法将更新用户名，并在操作中发挥业务规则的范围。

Answer 5

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

1. 为添加和更新创建完全独立的案例。
2. 创建一个处理添加和更新的单个案例。

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

尝试创建介于两者之间的东西很可能最终会带来两种模式的缺点。