와이어 객체 및 계산기의 비즈니스 객체 - 최고입니다.

Question

나는이 패턴을 반복해서보고 의견을 얻고 싶었다.

---

옵션 1 : 와이어 객체 및 비즈니스 객체 구성 :

와이어 objecT- 기계 (클라이언트 / 서버 등)에서 직렬화되어 전송 된 데이터. 이것은 Poco 객체입니다.

예를 들어:

public class Order
{
    public int Price;
    public int Amount;
}

비즈니스 대상 - 일반적으로 와이어 객체의 속성과 일부 또는 일부 계산 필드가있는 다른 클래스. 이것은 일반적으로 "와이어의"객체 위에 구성을 사용합니다.

public class OrderBusinessObject  
{  
     private Order _order;

     public OrderBusinessObject(Order o)
     {
          _order = o;
     }

     public int Price {return _order.Price;}  
     public int Amount{return _order.Amount;}  
     public int Total{return _order.Price * _order.Amount;}            
}  

---

옵션 2 : 대화에 의한 와이어 객체 및 비즈니스 객체에서 :

이것은 예제 1과 와이어 객체에서 동일하지만 구성을 사용하는 대신 비즈니스 객체는 번역을 사용합니다.

public class OrderTranslator
{
    public OrderBusinessObject Translate(Order o)
    {
         OrderBusinessObject bo = new OrderBusinessObject();
         bo.Amount = o.Amount;
         bo.Price = o.Price;
         return bo;
    }
}

public class OrderBusinessObject  
{    
     private int _price;
     private int _amount;

     public int Price {return _price;}  
     public int Amount{return _amount;}  
     public int Total{return _price * _amount;}            
}  

---

옵션 3 : 비즈니스 객체가 전혀없고 모든 계산이 별도의 계산기 클래스에서 수행되도록합니다. 참고 : 소비자는 와이어 객체와 계산기를 얻습니다.

public class Consumer
{
     public void ShowTotal(Order o)
     {
         Calculator calc = new Calculator();
         double total = calc.ShowTotal(o);
      }
}

여기에 모범 사례 나 패턴이 있는지에 대한 사람들의 의견을 얻고 싶었거나 이것은 단지 사용자 선호의 문제 일뿐입니다.

Answer 1

엔터프라이즈 레벨 시스템에서는 옵션 2를 선호하는 것이 좋습니다.이 방법은 SOA 환경에서 계약 우선 개발에 도움이되며 도메인 개체가 와이어 표현과 독립적으로 유지할 수 있습니다. 시간이 지남에 따라 계약 변경을 용이하게하고 도메인 및 데이터 접점이 서로의 부드럽게 변경 될 수 있습니다. 번역 코드는 약간의 고통 일 수 있지만 Automapper와 같은 도구를 사용하여 속도를 높일 수 있습니다.

즉, 모든 앱에서 이러한 수준의 유연성이 필요하지 않을 수도 있습니다.

나에게 옵션 3은 행동 지향 및 도메인 중심 원칙에 위배되는 경향이있어 동작이 외부화되어 빈혈 영역 모델로 이어지기 때문입니다. 도메인 모델은 데이터 계약에 의존하기 때문에 옵션 1은 도메인 구동 설계에 대해 약간 진행됩니다. 도메인 중심 모델에서 해당 도메인 객체는 독립적이어야합니다.