Dynamics AX에서 다중 관계 처리

실제 개발 과정에서 일대다(1:n)의 대상 관계는 매우 흔히 볼 수 있다. 예를 들어 판매 주문서(Sales order)에서 여러 개의 주문서(Sales lines)가 있을 수 있는데 이런 관계는 데이터베이스에서 제공하는 주/종 표 관련 관계를 직접 사용하여 실현할 수 있다.대상을 대상으로 분석하고 디자인하는 사상은 데이터베이스를 전체 모듈, 심지어 시스템 디자인의 주요 대상으로 제창하지 않는다.예를 들어 다대다의 대상 관계를 처리할 때 데이터베이스의 간단한 관련은 약간 힘에 부친다.이런 상황에서 디자이너들은 다대다의 관계를 일대다의 관계로 바꾸기 위해 새로운 데이터 테이블을 늘려야 한다.
 
아주 간단한 예를 들자면 학생과 선생님의 관계다.실제 생활에서 한 학생은 여러 선생님(국어, 수학, 영어 등)에게 가르칠 수 있는데, 선생님에게는?틀림없이 여러 학생을 가르칠 수 있을 것이다.그러면'가르치다/가르친다'는 관계는 다대다의 관계다.전통적인 데이터베이스 이론으로 이 관계를 처리할 때'Teaching'의 데이터 테이블을 도입해야 한다. 두 필드를 포함하는데 그것이 바로 StudentId와TeacherId이다. 이는 각 학생과 각 선생님 사이에'가르치기/가르치기'관계가 있음을 나타낸다.이 데이터 테이블의 도입을 통해 학생과Teaching 테이블은 일대다 관계로StudentId가 연결된다.선생님은 Teaching 테이블과도 일대다 관계로 TeacherId로 연결됩니다.데이터베이스 디자인의 측면에서 볼 때 새로운 데이터 테이블을 늘리는 것은 다대다관계를 해결하는 유일한 방법이 아니지만 오직 이런 방법만이 데이터베이스 디자인을 보완할 수 있다(3BNF에 도달할 수 있다).표면적으로 보면 이런 디자인은 합리적이다. 실체와 그 간의 관계가 이미 매우 명확하기 때문에 이런 디자인은 사람들이 사물에 대한 이해를 정확하게 나타낼 수 없다.예를 들어 위의 예에서 "Teaching"이라는 데이터 테이블의 정확한 의미를 어떻게 이해하시겠습니까?만약 고객이 컴퓨터를 모르고'교육'분야만 아는 분야의 전문가라면'Teaching'이 무엇인지 어떻게 설명해 주시겠습니까?당신은 그에게 "Teaching은 선생님과 학생 간의 교학 관계"라고 말했습니까?
 
이런 데이터베이스에 대한 디자인 사상(또는 수요를 얻자마자 데이터베이스 테이블의 디자인 사상을 어떻게 정의할 것인가)은 소형 시스템에 유리하고 적어도 실현의 진도를 가속화할 수 있다.만약 당신 앞에 초대형 소프트웨어 시스템이 있는데, 그 중에서 부지기수로 많은 종류와 그 간의 복잡한 관계를 포함한다면, 당신은 그것들을 효과적으로 데이터 테이블에 비출 수 있습니까?Dynamics AX에서 여러 쌍의 관계를 처리하는 데 매우 효과적인 방법은 바로'인터페이스'의 도입이다.실제 개발 과정에서 인터페이스는 아주 적게 쓰이는 것 같다.
 
위의 간단한 클래스 관계도(클릭하여 큰 그림 보기에서 ItemBase는 모든 프로젝트의 기본 클래스이고 BlueItem,GreenItem,RedItem,YellowItem은 ItemBase를 계승하여 GetColor 방법을 실현했다.IInvokable는 모든 인터페이스의 추상적인 것으로 BlueInvokable,GreenInvokable,RedInvokable는 IInvokable 인터페이스에 계승된다.BlueItem,GreenItem,RedItem,YellowItem은 ItemBase를 계승하는 동시에 각각 이 인터페이스를 실현했다.Invoker는 클라이언트 클래스(또는 호출 클래스,Consumer)로 Registry에서 유지되는 클래스의 속성을 통해 왼쪽에 있는 네 가지 Item을 호출합니다.
 
다음은 Registry입니다.getItems、Registry.register、Invoker.Invoke 방법의 실현은 이러한 위조 코드에서 Invoker가 어떻게 인터페이스를 통해 이 Items를 호출하는지 잘 알 수 있다.
 

public void Registry.register(ItemBase _itemBase)       

{      

    itemCollection.Add(_itemBase);      

}     

  

public ItemBase[] Registry.getItems(IInvokable _intf)      

{      

    ItemBase[] ret = new ItemBase[](MAX_ITEMS);      

    foreach (ItemBase itemBase in itemCollection)      

    {      

        if (itemBase.IsImplementing(_intf))      

            ret.Add(itemBase);      

    }      

    return ret;      

}      



public void Invoker.Invoke(IInvokable _intf)      

{      

    ItemBase[] items = registry.getItems(_intf);      

    foreach (ItemBase item in items)      

    {      

        print item.GetColor();      

    }      

    pause;      

}   

 
예를 들어 빨간색과 관련된 모든 Item을 호출해야 할 때, Red Invokable를 매개 변수로 Invoke 방법에 전달하기만 하면 된다.이 때, Invoker는Registry에서 RedInvokable 인터페이스를 실현한 모든 클래스를 얻어서 items에 그룹 형식으로 되돌려주고, Invoke 함수에서 각각의 item의GetColor 방법을 호출합니다.위의 그림에서 하나의 특례가 있는데 바로 Yellow Item이다. 이것은 두 개의 인터페이스를 실현했다. 그린인vokable와 RedInvokable이다. 이것은 Yellow Item은 두 곳에서 호출될 수 있다는 것을 나타낸다. (심지어 여러 곳에서 호출될 수 있다. implements 자구에 인터페이스 이름만 추가하면 된다) 이와 동시에 Invoke 함수에 전달된 파라미터가 RedInvokable일 때두 개의 Item이 호출됩니다(RedItem과 YellowItem, 이 인터페이스를 구현한 Item의 수에 따라 다름).총괄적으로 말하자면 이런 디자인 모델에서 한 항목은 여러 곳에서 호출될 수 있지만 반대로 어느 곳에서 여러 항목을 호출할 수 있다. 사실상 다대다관계의 대상을 대상으로 실현하는 것이다.
 
Dynamics AX에는 이러한 사용 방법이 이미 존재합니다. 바로 System checklist입니다.checklist의 item은 여러 개의 checklist에 나타날 수 있고, 각각의 checklist에는 여러 개의 checklist item이 있다.예를 들어 SysCheckListItemCompile는SysCheckListInterfaceUpgrade와SysCheckListInterfaceSetup 두 인터페이스를 실현했다. 이것은Upgrade와Setup의checklist에Compile 옵션이 나타나므로 고객에게 AOT에 대한Compile를 요구한다.SysCheckListInterfaceUpgrade 인터페이스를 실현한 클래스는SysCheckListItem 만이 아닙니다Compile.Dynamics AX의 checklist 시스템에서 Sys CheckList::get All CheckList Items 방법은 위의 Registry에 해당합니다.getItems 방법, SysCheckList::checkListItems 방법은 위의itemCollection에 해당합니다.AX 의 checklist 는 Registry 와 함께 제공되지 않습니다.register에 대응하는 방법은 개발자가 새로운 checklist item을 만들 때Sys CheckList::checkList Items에class number를 써서 등록하도록 요구합니다.
 
실제 프로젝트에서도 이런 디자인 모델을 사용했는데 ASI Project EDD021 Sales order Hold가 좋은 예이다.이런 모델의 도입은 앞으로 구조를 확장하는 데 매우 편리해졌다.이런 처리는 다대다 모델에 폐단이 하나 있는데 그것이 바로 프로젝트(item)의 등록이다.AX checklist 시스템은 개발자가 직접 Sys CheckList 클래스를 수정하고 새로 추가된 checklist item 클래스를 checkList Items 용기에 추가하여 등록하는 것입니다.ASI Project EDD021 Sales order Hold 프로젝트에서 우리는'운행시 등록'방식을 사용했다. 즉, 판매 주문이 잠금 판단을 실행할 때 item 등록을 완성하는 것은 합리적이지 않다. 왜냐하면 매번 잠금 판단을 실행할 때마다 새로운 item이 가입하는 것이 아니기 때문이다. 잠금 유형의 추가는 고주파 이벤트가 아니기 때문에 매번의 판정은 시스템 효율을 떨어뜨린다.