퇴근5분전

 오늘 작업중에 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프레임웍 만들때
비지니스 로직을 구현하던 중 유사하게 나타난 것이였다.


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

SQL을 다룰때마다 느끼는거지만... 참 재미있는게 많은데..

모르면 손가락 아프게 열심히 쳐야 한다는 사실...

항상 사용하는 것들 또 MSDN을 찾기 구찮아서 정리 해둔다..

아래 내용이면 테이블에 속성이나 자료형 길이등을 뽑아내서 스크립트화 가능한다... 

index_col( object_name( t.object_id ), i.index_id, c.column_id )  인덱스 컬럼인지 확인해준다.

type_name( c.system_type_id )  타입명을 반환

case 
when lower(type_name( c.system_type_id )) in ('char', 'varchar', 'nchar' ,'nvarchar', 'text' )  
then '('+convert( varchar(10), columnproperty( c.object_id, c.name, 'precision' ) )+')'       
when lower(type_name( c.system_type_id )) in ('numeric','decimal' ) 
then '('+ convert(varchar, c.precision) + ',' + convert(varchar, c.scale)+')'    
when lower(type_name( c.system_type_id )) in ('float','datetime', 'smalldatetime', 'tinyint', 'int', 'bigint' ) 
then ''           
else ''           
end  

요건 타입에 사용한 길이를 가져오는것인데...
원래 columnproperty( c.object_id, c.name, 'precision' )  이것인데...
잘 안된다.  총 길이를 자꾸 뱉어내서 정수형 INT, BIGINT같은건 길이가 나타남

 sys.tables  테이블들...

 sys.columns  컬럼들...

 sys.index_columns 인덱스컬럼들...

 sys.extended_properties  확장속성들...

 sys.foreign_key_columns  참조키 컬럼들...


DECLARE @TABLE_NAME NVARCHAR(776) = '테이블명'
 
select  [tablename]  = object_name( c.object_id ),
  [columnname] = c.name,
  [columndesc] = isnull(e.value, ''),
  [pk/fk]   = ltrim( rtrim( case
        when isnull( index_col( object_name( t.object_id ), i.index_id, c.column_id ),'') <> ''
        then 'pk'
        else ''
        end + '' +     
        case
        when isnull( f.constraint_column_id , '' ) <> ''
        then 'fk'
        else ''
        end )),
     [allowIsNull]  = isnull(  case when c.is_nullable = 0 then 'no' end , ''),
  [typename]  = type_name( c.system_type_id ),
  [columnlength] = case
        when lower(type_name( c.system_type_id )) in ('char', 'varchar', 'nchar' ,'nvarchar', 'text' ) 
        then '('+convert( varchar(10), columnproperty( c.object_id, c.name, 'precision' ) )+')'      
        when lower(type_name( c.system_type_id )) in ('numeric','decimal' )
        then '('+ convert(varchar, c.precision) + ',' + convert(varchar, c.scale)+')'   
        when lower(type_name( c.system_type_id )) in ('float','datetime', 'smalldatetime', 'tinyint', 'int', 'bigint' )
        then ''          
        else ''          
        end
from sys.tables t
inner join sys.columns c
on t.object_id = c.object_id -- and t.schema_id = 7
left outer join sys.index_columns i    
on c.object_id = i.object_id and c.column_id = i.column_id 
left outer join sys.extended_properties e         
 on c.object_id = e.major_id and c.column_id = e.minor_id and e.class = 1       
left outer join  sys.foreign_key_columns f     
on c.object_id = f.parent_object_id and c.column_id = f.parent_column_id 
WHERE @TABLE_NAME = case nullif( @TABLE_NAME, '') when '' then '' else OBJECT_NAME( t.object_id ) end  
order by t.name, c.is_nullable, c.name


이 구문이면 테이블정보를 쉽게 파악이 가능하고

확장속성에 스크립트를 걸어두면 속성이 컬럼명 옆에 붙어 나오므로 보기 더 좋음.

이걸 편집하면 테이블 스키마는 쉽게 뽑아낼 수 있음.

참고 # SP_DEPENDS 를 편집에서 나만의 프로시져로 만들어 사용하기도 한다..
각종 시스템 프로시져를 편집에서 사용이 편리한 놈으로 개조해서 사용하기도 함!!!

DataSet ds = new DataSet();
FlexGrid.Cols[ucTY_EVALUE].DataMap
              = new MultiColumnDictionary(ds.Tables[0], "DS_CODE", new string[]{"CD_CODE","DS_CODE"}, 1);


위처럼 FlexGrid에서 MultiColumnDictionary가 지원된다.

생성자가 몇가지 오버로드 되있는데 그중 위에 걸로 하면 될것 같고,
참고링크!!
http://helpcentral.componentone.com/nethelp/c1flexgrid/default.htm?turl=flexgridforwinformssamples.htm


위처럼 했을 경우

보이는건 DS_CODE 에 있는 것이 표시되고

콤보를 선택하려 클릭했을 때는

CD_CODE | DS_CODE  형태로 리스트로 아래로 뿌려진다.

맨앞 컬럼은 실제 선택시 값인데 DB에 저장할 때 위에는 DS_CODE로 코드가 아닌 이름을 그대로 저장하기 때문에
DS_CODE로 지정한 것 이다.