|
여러 작고 의미 있는 시도가 있었지만, 개인적인 생각은 역시나 책으로 회귀가 되네요. 이 책을 같이 읽으면서 토론을 해 봤으면 좋겠습니다. 시간 계획은 만나서 얘기하기로 하죠. 산 지는 꽤 되었는데,, 아직 못 읽고 있습니다. ㅠㅠ 어떻게들 생각하시는지... 이제 S 사이트에 혼자 남아서.. 다들 어떻게들 지내는지 궁금하네요. 1'st wave.... 파도 타기 잘들 하고 계시죠? ^___^
AOP(Aspect Oriented Programming)
컨셉이 마음에 든다... 비즈니스 로직, Logging, Exception, DAO 등을 각각 분리해서 개발한 다음 서로를 통합한다는 발상... Simplicity Rule 구현을 위한 원칙으로서 Once and Only Once와 맥을 같이 한다고나 할까... 분리된 기능을 의미에 따라 분류, 정의하고 통합을 위한 규칙(패턴)에 따라 기능을 결합한다..라는 대원칙이 AOP의 컨셉인것 같다. 기능을 분리하는 것은 중복을 확실히 제거할 수 있는 좋은 방법이고 유지보수의 강점이 있지만.. 문제는 기능을 통합하는 원칙이 무엇이냐는 것이다.. AOP에서는 이러한 분리와 통합에 대한 용어를 유형별로 정의하여 설계와 구현 시 원활한 커뮤니케이션을 도모하고 있다... Jointpoint, Advice, Pointcut, Aspect, Weaving, Target 등.. 의례 그렇지만.. 용어의 낮설음 보다는 커뮤니케이션의 효율성에 초점을 맞추면 생소함보다는 Simplicity Rule을 느낄 수 있을것 같다.. 용어의 개념을 파악하는 것이 AOP의 전체 사상을 이해하는데 도움이 될듯 하다...
애플리케이션 개발 시 테스트의 용이성은
개발 생산성과 품질에 상당한 영향을 미친다.. 그런 면에서 Spring 프레임워크의 테스트 전략 파악도 생산성과 품질을 올릴 수 있는 중요한 부분일 것이다.. Spring 프레임워크도 Junit 기반의 테스트가 가능하다.. 1. ApplicationContext에 대한 테스트 전략 -보통 Spring 프레임워크에서 ApplicationContext를 직접 생성하지는 않지만 테스트를 진행하기 위해서는 ApplicationContext를 직접 생성하고 테스트하고자 하는 빈에 대한 접근을 개발자들이 직접 프로그램적으로 구현할 수밖에 없다... -ClassPathXmlApplicationContext, FileSystemXmlApplicationContext 등의 클래스 이용 2. 퍼시스턴스 계층에 대한 테스트 전략 -테스트를 완료한 다음 이전 상태와 동일하게 초기화함으로써 각 테스트 메서드간의 독립성을 유지하는 것이 바람직... -테스트 케이스에서 ApplicationContext를 생성한 후 ApplicationContext API를 이용하여 DAO 인스턴스를 확보한 뒤 DAO에 대한 CRUD를 테스트 한다. (ApplicationContext 인스턴스를 통해 Dependency Injection 된 DAO 인스턴스 확보) 3. 비즈니스 계층에 대한 테스트 전략 -실질적인 업무에 대한 여러가지 케이스에 대한 테스트가 필요하므로 테스트 주기를 가능한 한 짧게 유지하는 것이 좋을 듯 하다... -최종 DAO와 연동한 비즈니스 로직에 대한 테스트는 계층간 정합성 데이터에 대한 dependency가 걸리므로 pseudo 데이터를 생성하여 반환하는 PseudoDAO 클래스를 만들어 연동 테스트 한다. -그러나 연동하여야 할 DAO가 많다면 위와 같은 방식에도 한계가 있으므로 pseudo 객체 프레임워크인 EasyMock(http://www.easymock.org/Documentation)을 이용한다. 4. 결론 EJB 아키텍처를 제외한 Non EJB 아키텍처와 Spring 프레임워크 사이의 테스트 용이성을 평가해 보면.. -Non EJB 아키텍처의 경우 논리적으로 각 계층을 분리하면서 각 계층의 인터페이스를 담당하는 클래스를 만들고 Factory 클래스를 통해 테스트한다. DAO도 마찬가지로 DAO 인터페이스를 구현하는 Pseudo 클래스를 추가하고 Factory 클래스를 통해 PseudoDAO를 생성하도록 소스 코드를 수정하여야 한다.. 이처럼 테스트를 위한 추가적인 코드 수정이 Non EJB 아키텍처에서는 필요하다.. -Spring 프레임워크의 경우 기존 소스 코드의 수정 없이도 EasyMock 프레임워크를 이용하여 테스트가 가능하다. 각 계층 사이의 의존관계는 인터페이스를 통해서만 통신하도록 구현하는 것이 가능하기 때문 이라나... 즉, Spring 프레임워크 기반으로 애플리케이션을 개발할 경우 디자인 패턴 중 Strategy 패턴(http://compstat.chonbuk.ac.kr/rightway/designpatterns/strategy.html) 을 사용할 수 있음으로 인해서 테스트의 용이성을 높여 소스 수정없이도 테스트하는 것이 가능하다...
요즘들어 부쩍 많이한 생각이지만..
"컨설팅"... 아직은 여건이 여의치 않은것 같다.. 무엇보다도 객체와 컴포넌트에 대한 미련이 너무 크다... 비즈니스에 대한 전문가가 되고 싶다는 것이 컨설팅에 대한 갈망 이었는데.. 굳이 컨설팅이 아니라 하더라도 비즈니스에 대한 내공을 키울 수 있을것 같다.. 객체, 컴포넌트, SOA... 더 깊게 파자... 한 2~3년 동안 파서 맥주공장 정도 차릴 수 있는 지하 암반수를 끌어 올리자.. -KJ
::~128
Lightweight 컨테이너 컨셉에 준하는 빈에 대한 생명주기 관리 또한 흥미로운 부분이다.. 기존 EJB 컨테이너를 이용하는 것보다 Lightweight한 빈 관리가 이루어 져야 하므로.. 빈 생명주기 관리에 대한 메카니즘을 파악하는 것이 Spring 프레임워크 컨셉 이해에 많은 도움이 될것 같다.. 역시, Dependency Injection의 방식에 따라 빈에 대한 생명주기 방식을 2가지로 구분할 수 있다.. 1. Spring 프레임워크 종속적 2. Spring 프레임워크 독립적 1번의 경우는 Spring 프레임워크에서 제공하는 인터페이스를 상속받아 빈의 생명주기를 관리하는 방식이고... 2번의 경우는 개발자들이 특정 메소드를 작성하여 빈 설정 파일에 생명주기에 관한 속성을 설정하는 방식이다.. Spring 프레임워크가 추구하는 방향은 POJO 빈이 Spring 프레임워크에 종속적이지 않도록 지원하는 것을 목표로 하고 있기에 2번 방식이 더 Spring 적이라 볼 수 있을것 같다.. 결국, Dependency Injection을 효율적으로 사용하려면 Lightweight 컨테이너 컨셉과 그것을 powerful하게 사용하기 위한 설정 파일에 대한 깊은 이해가 필수적이라는 생각이 든다..
::~106page
어제 회식이 있어서 많이 읽지 못했는데.. DI(Dependency Injection)에 대한 정리는 될 듯.. "Spring 프레임워크 워크북"의 필자는 DI(Dependency Injection)를 세가지로 분류 했는데.. 1. Setter Injection 2. Constructor Injection 3. Method Injection 우선 Injection이란 용어의 의미를 파악해 보면.. 외부에서 생성된 객체의 reference를 setter를 통해 전달 하는것을 의미하는데 setting 방식은 setter, constructor, method를 통해 가능하다. 즉, Injection의 주체가 누구냐에 따라 객체 제어권에 대한 책임을 갖는다. 개발자 or 컨테이너... 컨테이너를 통해 제어받는 것이 여러가지 편리한 잇점을 있지만 별도의 세팅 및 옵션 조절이 필요 하다.. 개발자가 직접 객체를 제어 하면 객체를 다양하고 미세하게 사용할 수 있지만 TX 등 여러가지 하위수준의 코드를 별도로 작성하여하는 번거로움이 따른다. 더군다나...완성도 높게 작성하기도 힘들다..그래서 무겁지 않은 Lightweight 컨테이너로 Dependency Injection을 표방하는 것이 Spring인것 같다... setter, constructor, method를 통한 세팅 방식에 따라 약간의 의미 차이가 있는데 정리하면, association 관계(by reference)인지 aggregation 관계(by reference) 인지 등으로 구분할 수 있을것 같다... -KJ
::~102page
Lightweight 컨테이너 라는 컨셉이 신선하다... 역시 여러 사람들이 EJB 기반 개발에 대한 고민을 하고 있었구나 라는 공감대가 느껴진다... Non-EJB와 EJB의 장점만을 take 하여 시스템을 구축하고 생산성도 높이겠다는 목표가 확실해 보인다. 그 구체적인 실현으로 IoC(Inversion of Control)를 언급하고 있는데 필자는 IoC를 DL(Dependency Lookup)과 DI(Dependency Injection)로 구분하고 있다..적절한 분류이다. 용어보다는 의미가 적절하다.. *DL(Dependency Lookup): 개발자들이 컨테이너에서 제공하는 API를 이용하여 사용하고자 하는 빈(Bean)을 Lookup 하는 것 -컨테이너 API를 사용하므로서 컨테이너에 대한 dependency가 높아지고 portability(이식성)이 낮아지는 단점이... DI(Dependency Injection)에 대해서는 읽고 있는 중이다.. Injection이라는 용어도 적절한것 같은데... 더 읽어 봐야 겠다.. -KJ
::~74page
"Spring 프레임워크 워크북" 마음만 먹고 있었는데 본격적으로 읽기 시작했습니다.. DDD에 대한 목표를 말씀해 주신 MJ님과 다양한 의견을 교환하기 위해서라도 열심히 읽으려 합니다.. 책 앞부분에 나온 내용 중 Lightweight 컨테이너라는 컨셉이 흥미로웠는데요... 좀 더 읽어 보고 Ligntweight에 대한 생각을 정리해서 올리 겠습니다. -KJ
[Xp Simplicity Rules]
룰 4개 중에 가장 중요하다 싶으신걸 하나 잡아서 집중적으로 보고 오시는것도 좋을거 같네요. 전 4번 "Once and only once"가 가장 중요하지 싶습니다. 링크 표시를 좀 해볼려고 []를 이용했는데, 좀더 좋은 아이디어가 있으면 댓글 좀.. - MJ
Source: Vault 2005 Consulting Survey 10위권 안에서는 아는 컨설팅 회사가 2개밖에 안되는 군요...ㅎㅎ MJ님이 좋아하시는 BCS는 13위네요~ 2006년도에 새로 진입한 회사들도 눈에 띄구요. 음~우리들이 앞으로 들어갈수 있는 좋은 회사들이 참 많다는 생각이 드네요^^ 자 다들 하나씩 골라보세요~ - fusionpak
|
 by 스터디소모임 카테고리
이전블로그
이글루링크
최근 등록된 덧글
 |
