Commad? 응용...

 오늘 작업중에 ERP에서 그룹웨어 전자결재관련 링크 콜! 하는 부분에 대한 작업을 하였음.

프레임웍 쪽은 내가 관여할 부분이 안되므로... 단순한 코딩보다

그룹웨어 관련 명령을 관리할수 있는 걸 만들어두면 추후 좋지 않을까 해서 ...

작업을 시작하였음.  코드는 기록 못하니... 패턴 형태만 기록함.

우선 Event에 대한 동작은 기능에서 제외했다.( 객체사용에 있어서 이벤트까지 필요없는 것임. )

구현에 있어 떠오른 패턴은 커맨드패턴이다. 약간의 변형을 시켜 만들어 보았다.


#그룹웨어 관련 데이타 인터페이스
         _. 멤버1
         _. 멤버2
         _. 멤버...
         _. 멤버 유효성체크();    

#그룹웨어 명령 열거형
         _. 쓰기
         _. 읽기

#그룹웨어 헬퍼  :   데이타 인터페이스
        _. static 쓰기명령.Execute(  데이타인터페이스 )
                    {  데이타인터페이스.Validate( 쓰기 ); 
                       데이타처리( 쓰기,   데이타인터페이스 );   }
        _. static 읽기명령.Execute(  데이타인터페이스 )
                    { 데이타인터페이스.Validate( 읽기 );
                       데이타처리( 쓰기, 데이타인터페이스 ); }
        _. static 데이타처리( 명령열거형, 데이타인터페이스 )
                    {  ToDo: 작업... }
        _. static 버튼제어(  대상버튼..., 상태값1, 상태값2.... ) //오버로딩.
                    {  상태값들 별로 대상버튼 제어...  }

이렇게 해두면 읽기, 쓰기 에 각각 데이타를 활용할 수 있게 만들고, 또다른 명령이 필요하면

명령열거형에 새명령 추가. 
데이타에 유효성체크에 새명령에 대한 코드 추가.
헬퍼에 새명령 메서드 추가.
헬퍼에 버튼제어에 로직 추가.

이렇게 처리가 가능하다.

실제 사용할때는 !!!

# 데이타 조회
        1. 그룹웨어헬퍼 인스턴스에 데이타 셋팅!
        2. 그룹웨어헬퍼 인스턴스.버튼제어( 대상버튼..., 상태값1, 상태값2.... )

# 쓰기명령
        1. 그룹웨어헬퍼.쓰기명령.Execute( 그룹웨어헬퍼 인스턴스 );

# 읽기명령
        1. 그룹웨어헬퍼.읽기명령.Execute( 그룹웨어헬퍼 인스턴스 );


 단 몇줄로 쉽게 구현이 가능하고 프레임웍 내에 귀속된다고 했을 시 어떨까?

_ 내 생각엔....
장점. 
1. 역할이 분명하고, 헬퍼 자신이 가져야 할 데이타가 무척 제한적일 수 있다.
    _. 그룹웨어와 관련된 데이타에 대해 제한을 둘수 있다.
        erp와 그룹웨어와의 경계를 만든다.
     
2. 따라 처리 로직을 쉽게 찾을수 있고 새명령코드를 만들때 쉽다.
    _. 실제 많은 명령을 만들어봐야 어떤지가 나올 것 같다.
       유효성체크는 항상 고민이다... 추후 이녀석에 대해 써볼 예정임.
  
3. 담당 개발자가 작성할 소스를 줄일 수 있다.
   _. 굉장히 중요하다고 생각함. 솔루션에서 유지보수를 힘들게 하는 것으로는 
     일정에 대한 압박으로 코드 자체를 휘저어 놓는 것인데...
     ( 나랑은 좀 먼 얘기? 난 일정마감이 와도 내맘대로.. 시간이 많아도 내맘대로... 고쳐야 할 습관이기도 함... )
   _. 유지보수를 하는 입장에서의 소스 버젼이 다른 것들에 대해서는 참 접근이 쉽지 않다는 것이다.
     특정 기능이 필요한 시점에서 정말 단발성이냐 아니냐에 따라 클래스 생성여부를 결정하는 나로써는... 
    이번 그룹웨어헬퍼는 사용하는 페이지가 7이었고. 동일한 데이타구조와 함께 그 기능이 동일하기에 
    클래스로 특화 시켜놓았다. 그리고 주석을 붙여놓았는데...
    
단점.
1. 동작에 대한 문서가 상세하게 작성되어야 한다.
   음 난 정말 상세하게 적어두려고 읽기 좋도록 만들어보려고 노력은 하는데... 어렵다... 
   정리된 문서 읽는 것도 긴글들은 벅차다.
      
2.  이러한 패턴에 대해 유지보수 개발자는 이해하고 있어야 한다.
   UI담당 개발자가 추가적인 확장이 어렵다. 곧, 헬퍼 외부에 코드를 남발해야 한다.
   ( 이는 프레임웍 담당 개발자가 확장시켜주면 되는데... )

3. 아무래도... 이게 실제 프레임웍을 소유하고 있는 개발자에게 부담이 되지 않을까?
   남의 소스를 반가워 할 개발자는 그리 많치 않을테니..


이렇게 정리 해보았다.


 퇴근중에 간단히 몇가지 생각해보니... 위 패턴은 내가 2.0프레임웍 만들때
비지니스 로직을 구현하던 중 유사하게 나타난 것이였다.


다음엔 디자인 패턴 몇개를 골라서 닷넷이 가진 매력을 뽐내볼까나...