닷넷 3.5는 좋은 설계 디자인을 발전시킨다
닷넷 3.5는 업계 전반에서 요구하는 구조적인 디자인 패턴들을 쉽게 구현할 수 있도록 도와 주기 때문에 좋은 품질의 프로그램을 만들 수 있다. 다음은 이 패턴들 중 중요한 것을 정리해 본 것이다
- N-티어 패턴은 사용자 인터페이스와 비즈니스 오브젝트 및 데이터 계층을 분리할 수 있도록 해준다
- MVC(Model-View0Controller)패턴은 최근에 ASP.NET MVC Framework로 통합되어었다 그래서
비주얼 스튜디오를 이용해서 MVC 디자인을 선택적으로 적용할 수 있다
- Observer (옵저버) 패턴은 흔히 출판(Publish)과 구독(Subscribe)으로 널리 알려진 패턴이다
- Factory Method패턴은 오브젝트의 생성을 추상화한다
- Chain of Command 패턴은 명령 오브젝트와 처리 오브젝트를 분리한다.
- Singleton 패턴은 오직 하나의 클래스 인스턴스가 존재할 수 있다.
좋은 디자인 설계를 파헤치다?
이전 닷넷 버전과 MFC의 경우에도 구현하고자 하는 구조 패턴을 구현할 수 있고 또한 최상의 결과를 얻을 수 있다
예를 들어, 많은 프로그래머들이 중요하게 생각했던 구조 패턴은 MVC패턴이었다. 이 패턴은 해결하려고 노력하는 문재들은 소프트웨어적으로 표현하는 모델(model)과 사용자와 직접 접촉하는 뷰(view)및 버튼 이벤트나 시스템 이벤트를 처리하는 컨트롤러로 분리한다
하지만 일반적인 닷넷으로는 이 패턴을 구현하는 것은 거의 불가능하다. 왜냐하면, 전통적인 컨트롤로의 역할이 운영체제, 프레임워크, 컨트롤, 이벤트 처리기 등으로 분산되어 있기 때문이다. 게다가, 실제로 많은 닷넷 프로그램들은 모델을 가지지 못하고 단지 뷰와 저장하기 위한 다소의 데이텀나을 가지고 있다
두번째로 인기 있는 패턴은 "n-티어" 프로그램을 구축하는 것이다. 일반적으로 가장 널리 사용되는 것은 UI 를 담장하는 표현 계층, 비즈니스 로직 데이터 계층으로 분리하는 3-티어이다. 하지만 이러한 방식은 비즈니스 로직 계층이 없어져서 결군은 UI와 데이터 계층만 남는 2-티어가 되기 쉬웠다
많은 닷넷 프로그래머에게는 비즈니스 계층이 하는 일조차도 명확하지 않다. 또한, 비즈니스 오브젝트들은 실제보다 이론상으로 더 많은 값을 갖는 것처럼 보이기 떄문에 데이터오브젝트나 컨트롤에서 유지해야 정보가 매우 많아 보이게 된다. 사실, 비즈니스 오브젝트의 알맹이만 필요하지만 껍데기는 필요가 없다
이번 장의 후반부에 좀더 자세한 이야기를 하기 위해, 다음고 ㅏ같은 질문을 던져 보자. 사용자가 로그인할 때, 고용인이나 관리자처럼 사용자의 "역할(role"에 따라 페이지가 달라지도록 분기하는 코드가 있다면, 어느 부분에 있어야 할까? 3-티어 패턴에서는 이러한 코드가 사용자들과 직접 만나는 프리젠테이션계층(Presentation layer)에 속하지 않는다. 또한 사용자의 역할이 저장되어 있는 데이터 계층(data layer)에 있을 수도 없다. 오히려, 정보를 캡슐화한 클래스에 있어야 한다고 주장한다. 이런 클래스들은 모델, 즉 비즈니스 로직의 일부이다.
닷넷은 데이터 계층을 ADO.NET 오브젝트들을 통해서 프리젠테이션 계층(주로 컨트롤들)과 직접 연걸되도록 설계된 웹 프로그램을 권항하는 것처럼 보였다. 특히, 데이터 소스 컨트롤들이 소개되면서 이러한 경향이 증가했다.
하지만, 많은 프로그래머들이 즐겨 사용하던 두 계층 간의 직저 연결은 DataGrid 같은 컨트롤과 DataSet 같은 데이터 오브젝트들 간의 강력한 결합을 만들어 냈고, 한 계층이 변경되면 다른 계층도 변경해야하는 결과로 이어졌다 . 이것은 바로 n티어 패턴이 해결하고자 했던 문제와 정확하게 일치했다. 아울러, 기업용 프로그램을 만드는데 장애 요소로 작용했다
이 부분을 오해하지 않길 바란다. 과거에도, 많은 닷넷, MFC 심지어 C프로그래머들고 매우 잘 디자인되 n-티어 혹은 MVC프로그램들을 만들어 냈다. 하지만 그들이 사용했던 도구 프로그램들은 이러한 프로그램 디자인 설계에 쉽게 이용할 수 없었다. 이러한 기반도 불구하고 그들은 성공적으로 프로그램을 만들어 냈다
아마도 산업 표준으로 사용되는 최상의 설계 디자인이라는 전제와 대비되는 가장 터무니 없는 프레임워크 중 하나를 웹서비스의 구현에서 볼 수 있었다. 마이크로소픝는 아주 좋은 의도를 가지고 프로그래머들이 웹서비스를 사용 할 수 있도록 하면서 RPC(Remote Procedure Call)를 통해 내부적으로 사용되는 SOAP 과 XML의 내용을 숨겼고, 프로그래머들에게 웹서비스를 클라이언트에서 프락시를 통해 제공되는 메소드들의 집합으로 생각하도록 권장했다. 클라이언트들은 단지 메소드들을 호출했고 결과가 빠르게 반환되었다. 그래서, 개발자들이 XML을 볼 기회가 전혀 없었다.
불행히도, 모든 프로그래머가 알고 있듯이 웹서비스는 데이터 교환을 위해 고안되었고, 이러한 작업을 위해 첫 번째 할 일은 계약(contract)과 WSDL 문서를 만드는 것이다. 마이크로소프트가 제공하는 프로그램으로는 이러한 작업을 할 수 없었다. 사실 , 꼭 그렇지만은 않았지만 그리 호락호락한 작업은 아니었다. 서비스의 제공자나 소비자들이 WSDL설계를 시작해서 관련 클래스들을 구현할 때까지 쉬운 방법이 전혀 없었다. RPC의 환상은 웹서비스를 쉽게 만들겠다는 것이엇지만, 대부분은 환상이 그렇듯이 얼마 지나지 않아 개발자들이 이 기술을 진정으로 이해하는것을 방해했고, 더 복잡한 업무 요구를 처리할 수 없게 되었다
소프트웨어 개발에서 , 업계 베테랑의 경험은 젊은이나 기술적인 노하우 이상의 가치를 인정받는다. 온라인 뱅킹을 만드는 작업을 가정해 보자. 그러한 프로젝트에 처음 부딪쳤을때, 할 수 있는 것, 할 것, 앞으로 잘못될 수 있는 것에 대한 개념이 없다. 사실, 프로젝트에 관한 질문조차도 제대로 하고 있는지도 모를 수도 있다. 왜냐면, 기존 시스템들고 협업을 하다 보면 일어날 수 있는 뜻하지 않는 위험이나 예상하지 못한 문제들을 다루는 교과서는 기술 매뉴얼은 없다
소프트웨어 디자인 패턴
소프트웨어 디자인 패턴들은 짧은 시간(디자인 패턴 책을 읽고 자신의 것으로 소화하는)안에 수년간 진행된 여러 프로젝트들을 통해서 얻은 경험을 전달하려는 시도이며, 프로젝트의 실패는 피하면서 다른 사람들의 경험을 이용할 수 있도록 해준다
소프트웨어 디자인 패턴은 사실 건축 업계에서 유래했다 1970년대 건축가이자 도시 공학 자인 크리스토퍼 알렉산더는 사람들이 자신에게 필요한 건물은 건축가들보다 더 잘 알고 있다라는 결론에 도달했다. 알렉산더는 세월이 흘러도 다시 사용되는 디자인 구조가 바람직한 결과 이어진다는 것을 알았다. 그래서, 그가 얻었던 경험과 지혜를 문서화하고 출판해서 다른사람들에게 도움이 되도록 했다.
다행히, 소프트웨어 분야에서도 , 컨트벡과 워트 커닝햄 이 프로그래밍에도 패텅을 적용하자는 아이디어를 실험에 옮겼고 그결과 1987년 OOPSLA 컨터런스에서 발표했다. 컨퍼런스 후에도 이들은 다른 사람들과 이 작업을 계속 했다
디자인 패턴이 프로그래머들 사이에 인기를 얻은 것은 1994년에 Addision-Wesley에서 출간된 에릭 감마의 책
[Design Patterns:Elements of Reusable Object-Oriented Software] 이 출간된 이후이다
최첨단 소프트웨어 개발을 진행하는 많은 기업에서는 이 책을 직원들이 읽어야 할 책의 최상위의 선정했다. 같은 해에, 첫 번째 PLOP(Pattern Languages of Programs)컨퍼런스가 개최되었고, 이듬해 PPR(Portland Pattern Repository)이 디자인 패턴들을 문서화하기 위해 설립되었다
그 이후, 디자인 패턴은 다소 약화되었고 실제보다는 이론적으로 많이 다뤄졌다. 이러한 이유 중의 하나는 "패턴과 친숙한(Pettern-friendly)"개발환경이 거의 없었기 때문이다. 하지만 닷넷 3.5가 발표되면서 , 비로소 디자인 패턴 커뮤니티에서 문서화한 핵심 디자인 패턴이 많이 통합되거나 권장을 지원하는 프레임워크를 갖게 되었다.
- 참고 Programming .Net 3.5 by Jesse Liberty and Alex Horovitz.