|
|
번역/ScottGu's Blog 2008. 1. 25. 16:06
.NET -
관리되는 코드와 관리되지 않는 코드 간의 마샬링: 상하이에 있는 제 팀원인 Yi Zhang과 Xiaoying Guo는 네이티브 코드를 호출하는 CLR의 마샬링 상호 운용 기능에 대한 훌륭한 MSDN 아티클을 작성하였습니다. 특히 그들이 작성한 플랫폼 호출 상호 운용 도우미 응용 프로그램(P/Invoke Interop Assistant application)은 네이티브 메서드를 호출할 때 필요한 플랫폼 호출 시그니처를 매우 쉽게 생성해 냅니다. 관리되지 않는 코드와 관리되는 코드 간의 상호 작용 작업을 하는 사람들은 반드시 갖추어야 할 툴입니다. -
.NET 프레임웍 3.5 포스터: Brad Abrams는 .NET 프레임웍 3.5의 새롭고 멋진 포스터를 다운로드하는 방법에 관한 포스트를 작성하였습니다. (여러 가지 파일 포맷이 제공됩니다.) IIS -
마이크로소프트 웹 배포 툴 테크니컬 프리뷰1: 어제 IIS 팀은 마이크로소프트 웹 배포 툴의 첫번 째 프리뷰에 관한 포스트를 게시하였습니다. 마이크로소프트 웹 배포 툴은 IIS6과 IIS7를 모두 지원하며, 자동화된 배포, 동기화, 웹 서버 상에서의 응용프로그램 마이그레이션을 가능하게 합니다. ASP.NET 응용 프로그램의 배포를 자동화할 방법을 찾고 있다면, 이 툴이 바로 그 것입니다. 더 상세한 내용은 링크된 페이지의 하단에 있는 따라하기 (특히 "MS Deploy 소개" 항목)를 참고하십시오. 이 툴은 자동화된 배포를 더욱 쉽게 만드는 놀라운 툴입니다. 도움이 되길 바라며, 스캇
번역/ScottGu's Blog 2008. 1. 16. 16:06
원문 : .NET Framework Library Source Code now available 지난 시월에 저는 닷넷 프레임웍 라이브러리의 소스 코드가 공개될 것이며 비주얼 스튜디오 2008에서는 닷넷 프레임웍 라이브러리의 디버깅이 지원될 것이라는 블로그를 쓴 적이 있습니다. 기쁘게도 오늘 이것이 가능하게 되었습니다. 특히 아래 닷넷 프레임웍 라이브러리의 소스 코드는 지금 당장 볼 수 있고 디버깅도 가능합니다. - .NET Base Class Libraries (including System, System.CodeDom, System.Collections, System.ComponentModel, System.Diagnostics, System.Drawing, System.Globalization, System.IO, System.Net, System.Reflection, System.Runtime, System.Security, System.Text, System.Threading, etc).
- ASP.NET (System.Web, System.Web.Extensions)
- Windows Forms (System.Windows.Forms)
- Windows Presentation Foundation (System.Windows)
- ADO.NET and XML (System.Data and System.Xml)
현재는 더 많은 프레임웍 라이브러리(LINQ, WCF, Workflow 포함)를 위 리스트에 추가하기 위한 프로세스를 진행 중입니다. 비주얼 스튜디오 2008의 참조 소스 접근을 활성화하기 비주얼 스튜디오 2008에서 닷넷 프레임웍 소스 접근을 하기 위해 필요한 설정을 하는 데는 단지 몇 분 밖에 걸리지 않습니다. Shawn Burke는 이 작업에 대한 구체적인 과정을 상세하게 설명한 세세한 블로그 포스트를 이 곳에 포스팅 하였습니다. 만일 설정하는 데 문제가 있거나 질문이 있다면, 이 곳에 있는 MSDN의 Reference Source Forum에 질문을 올려주시기 바랍니다. 닷넷 프레임웍 라이브러리 소스로 들어가기 위에 있는 Shwan의 포스트의 설명에 따라 설정 단계를 마치고 나면, 닷넷 프레임웍 라이브러리의 디버그 심볼을 동적으로 로드하고, 소스 코드로 들어갈 수 있습니다. 프레임웍 코드를 디버깅 하면 VS2008은 필요한 심볼과 소스 파일을 MSDN 참조 서버에서 다운로드 할 것입니다. 
소스 파일에는 개발자의 주석이 포함되어 있습니다. 위 그림에서는 Control 기초 클래스의 Dispose 메서드에 있는 개발자 주석의 예를 볼 수 있습니다. 가끔씩은, 지나간 버그 / 버그의 추적 번호 / 특정 코드를 선택한 이유에 대한 정보를 제공하는 워크아이템 추적 데이터베이스에 대한 주석을 보시게 될 수도 있습니다. 예를 들어, 위 주석에서는 닷넷 프레임웍 이전 버전과의 역 호환성을 지키기 위해, 이 필드에 null을 대입하면 안 된다는 것을 알리고 있습니다. 그리고 위 주석에서는 필드에 null을 대입하지 않았기 때문에 고칠 수 있었던 역 호환성 버그에 대한 정보도 표시하고 있습니다. 참조 라이센스 닷넷 프레임웍 소스는 읽기 전용 참조 라이센스로 공개됩니다. 지난 시월에 우리가 소스를 공개할 것이라고 발표했을 때, 어떤 분들은 소스를 보게 됨으로써 그들이 안게 될 잠재적인 부담에 대해서 걱정을 하였습니다. 이런 문제를 명확히 하고 또 그러한 걱정을 덜어드리기 위해 우리는 라이센스를 약간 변경하였습니다. 닷넷 프레임웍과 “동일하거나 실질적으로 동일한 특징 혹은 기능”을 가지고 있는 윈도우 플랫폼용이 아닌 소프트웨어를 개발하는 개발자에게는 이 라이센스가 적용되지 않습니다. 윈도우 플랫폼용 소프트웨어를 개발하는 개발자는, 닷넷 프레임웍과 “동일하거나 실질적으로 동일한 특징 혹은 기능”을 가진 소프트웨어를 개발한다고 할 지라도, 소스 코드를 볼 수 있습니다. 정리 소스 코드에 대한 접근과 닷넷 프레임웍 라이브러리의 디버거 통합은 닷넷 개발자들에게 있어 매우 가치 있는 일이 될 것입니다. 닷넷 프레임웍 라이브러리의 소스를 살펴 보면, 닷넷 프레임웍 라이브러리가 어떤 식으로 구현되었는지를 이해하는 데 더 많은 통찰을 얻게 될 것이고, 그러면 더 훌륭한 애플리케이션을 작성할 수 있게 되고 닷넷 프레임웍 라이브러리를 더 잘 사용할 수 있게 될 것입니다. 도움이 되길 바라며, 스캇
번역/ScottGu's Blog 2008. 1. 8. 16:11
원문 : Visiting China, South Korea and Japan the Next Two Weeks 이번 금요일 부터 저는 열흘 간 아시아를 방문합니다. 업무상 출장은 사실 별로 재미있지 않지만, (작년에 저는 비행기를 70번도 넘게 탔습니다.) 아시아는 처음 방문하는 것이라 이번 여행에는 많은 기대를 하고 있습니다. 중국(베이징, 상하이, 심천), 한국(서울), 일본(도쿄)를 방문하여, 이벤트 참석, 고객과의 미팅을 하고, 또 중국에 있는 우리 개발팀도 방문할 예정입니다. 아래는 이번 출장에서 제가 참석할 프레젠테이션의 세세한 목록입니다. 혹시 이 프레젠테이션들에 참석하거나 또는 이 프레젠테이션들에 대해서 더 많은 것을 알고 싶으신 분들은 참고하시기 바랍니다. - 중국 (베이징, 1월 13일)
- 중국 (상하이, 1월 14일) <- 업데이트 되었습니다.
- 남한 (코엑스 컨퍼런스 센터 310호, 1월 17일)
- 일본 (도쿄 록뽄기에 있는 이즈미 가든 갤러리, 1월 21일)
작년에는 행복하게도 제 블로그 포스트를 다른 언어(중국어와 일본어 포함)로 번역해주는 훌륭한 자원봉사자들이 생겼습니다. 아래 링크는 영어가 모국어가 아닌 분들을 위한 피드들입니다. 이번 출장길에 Xuegen Jin (이 분은 제 포스트를 중국어로 번역하여 HongChao Wang의 싸이트에 호스팅 해주십니다.)와 Chica(이 분은 제 포스트를 일본어로 번역해 주십니다.)를 만나 고맙다는 인사를 개인적으로 할 수 있는 기회가 있으면 좋겠습니다. 감사합니다. 스캇
번역/ScottGu's Blog 2008. 1. 7. 16:07
원문 : Dynamic LINQ (Part 1: Using the LINQ Dynamic Query Library) LINQ (언어 통합 쿼리)는 VS2008과 .NET 3.5에서 제공되는 새로운 기능의 하나입니다. LINQ는 데이터 쿼리라는 개념을 .NET에 있어서 가장 중요한 프로그래밍 개념으로 만들고, 프로그래밍 언어에서 효율적으로 쿼리를 표현할 수 있게 합니다. LINQ가 좋은 점 중 한 가지는 VB와 C#에서 형식에 안전한 쿼리를 작성할 수 있다는 것입니다. 즉, LINQ 쿼리는 컴파일 타임에 검사가 되며, 작성한 코드는 완전한 자동완성과 리팩토링을 지원합니다. 
형식에 안정한 쿼리를 작성하는 것이 대부분의 경우에는 바람직한 일이겠지만, 동적으로 쿼리를 작성하는 유연함이 필요한 경우도 있을 것입니다.예를 들어서, 최종 사용자인 비즈니스 분석자가 드롭다운을 이용하여 스스로 자신에게 필요한 쿼리(또는 뷰)를 만드는 것과 같이, 애플리케이션에 비즈니스를 이해하는 UI를 탑재할 수 있습니다. 예전에는 이러한 동적 쿼리 시나리오를 문자열을 서로 연결하여 동적 SQL 쿼리를 생성하는 것으로 해결하곤 하였습니다. 최근에 몇몇 분들이 제게 메일로 물어보시기를, LINQ를 사용할 때는 이런 시나리오를 어떻게 처리할 수 있냐고 하셨습니다. 아래 포스트는 LINQ 팀에서 제공하는 동적 쿼리 라이브러리를 사용하여 LINQ 쿼리를 동적으로 생성하는 방법에 대해서 설명합니다. LINQ 동적 쿼리 라이브러 다운로드하기 VS 2008 샘플 다운로드 페이지에는 동적 쿼리 LINQ 헬퍼 라이브러리를 포함하는 VB와 C# 샘플 패키지에 대한 링크가 있습니다. 동적 쿼리 라이브러리(그리고 그에 대한 문서)로 바로 가는 링크는 아래와 같습니다. VB와 C#의 DynamicQuery 샘플에는 형식에 안전한 언어 연산자 대신 문자열 매개변수를 가지는 익스텐션 메서드를 사용하여 LINQ 쿼리를 표현할 수 있는 헬퍼 라이브러리의 소스 구현이 포함되어 있습니다. DynamicQuery 라이브러리의 C# 혹은 VB 구현물을 프로젝트에 복사/붙여넣기 하면, 엔드 유저의 입력에 따라 더욱 더 동적으로 LINQ 쿼리를 생성할 수 있습니다. 간단한 동적 쿼리 라이브러리 예제 LINQ to SQL, LINQ to Objects, LINQ to XML, LINQ to Entities, LINQ to SharePoint, LINQ to TerraServer 등을 포함하여 어떠한 LINQ 데이터 프로바이더에 대해서도 DynamicQuery 라이브러리를 사용할 수 있습니다. LINQ 쿼리를 작성하기 위해 언어 연산자나 형식에 안전한 람다 익스텐션 메서드를 사용할 필요 없이, 동적 쿼리 라이브러리를 이용하면 어떤 문자열 식도 수용할 수 있는 익스텐션 메서드 기반의 문자열을 사용할 수 있습니다. 예컨데, 아래는 Northwind 데이터베이스에서 데이터를 가져와 ASP.NET GridView 컨트롤에 표시하는, 일반적인 형식 안전한 LINQ to SQL VB 쿼리입니다. 
위 쿼리를 LINQ DynamicQuery 라이브러리를 사용하여 다시 쓴다면 다음과 같습니다. 
조건절(where)과 정렬절(orderby)이 코드 식이 아닌 문자열 식을 가지는 것을 주목하여 주십시오. 이 문자열 식들은 늦은 바인딩이 되기 때문에 동적으로 생성될 수 있습니다. 예를 들어, 엔드 유저인 비지니스 분석자가 (임의의 조건절을 포함하여) 스스로에게 필요한 쿼리를 생성할 수 있도록 할 수도 있는 것입니다.
동적 쿼리 라이브러리 문서 위 VB와 C# 동적 쿼리 샘플에는 동적 쿼리 라이브러리 익스텐션 메서드를 사용하는 상세한 방법을 담고 있는 HTML 문서가 포함되어 있습니다. 동적 쿼리 라이브러리를 더 깊이 사용하기 위해서는 반드시 이 문서를 볼 필요가 있을 것입니다. 
동적 쿼리 라이브러 예제의 다운로드와 실행 저는 LINQ to SQL을 사용하여 Northwind 샘플 데이터베이스를 쿼리하는 ASP.NET 웹사이트에서 동적 LINQ 라이브러리가 응용되는 간단한 VB와 C# 예제를 작성하였습니다. 아래 링크에서 이를 다운로드 받을 수 있습니다. 위 예제는 무료인 Visual Web Developer 2008 Express 나 VS 2008에서 모두 동작합니다. 동적 LINQ 쿼리를 생성하는 다른 방법들 동적 쿼리 라이브러리를 사용하는 것은 대단히 간단하고 쉽습니다. 또한 대부분의 쿼리가 동적이라서 엔드 유저에게 동적 쿼리를 만드는 UI를 제공하여야 하는 경우에는 특히 유용합니다. 다음 블로그 포스트에서는 동적 LINQ 쿼리를 작성하는 방법에 대해 더 깊숙이 살펴보도록 하겠습니다. 또한 형식 안전한 조건자 메서드를 사용하여 동적 LINQ 쿼리를 작성하는 방법들에 대해서도 살펴보고자 합니다. (C# 3.0 In a Nutshell book의 탁월한 저자인 Joseph와 Ben Albahari는 이미 이에 대한 훌륭한 기사를 여기에 썼습니다.) 도움이 되길 바라며, 스캇
번역/ScottGu's Blog 2007. 10. 14. 01:24
원문 : ASP.NET MVC Framework  오랜 시간 동안 ASP.NET에 대해 많은 사람들이 요청한 기능 중 한 가지는 모델-뷰-컨트롤러 (MVC) 아키텍쳐에 기반한 웹 응용프로그램 개발을 지원해달라는 것이었습니다.
지난 주말에 오스틴에서 열린 Alt.NET 컨퍼런스에서 저는 현재 우리 팀이 작업하고 있는 ASP.NET MVC 프레임웍의 첫번째 퍼블릭 데모를 시연하였습니다. Scott Hanselman의 블로그에서 제가 한 프리젠테이션을 보실 수 있습니다. ASP.NET MVC 프레임웍은 올해 연말에 퍼블릭 프리뷰가 출시될 예정입니다. 그리고 내년 상반기에는 ASP.NET을 완벽하게 지원하는 버전이 출시될 것입니다. 모델 뷰 컨트롤러 (MVC) 프레임웍이란? MVC는 애플리케이션의 구현을 세 부분(모델, 뷰, 컨트롤러)으로 나누는 프레임웍 방법론입니다. - MVC에 기반한 애플리케이션에서 "모델"은 상태를 관리하는 책임을 지고 있는 컨퍼넌트입니다. 주로 이 상태는 데이터베이스에 저장됩니다. (예를 들어, 주문 데이터를 표현할 때 사용되는 Product 클래스는 SQL의 Products 테이블에서 가져올 수 있습니다.)
- MVC에 기반한 애플리케이션에서 "뷰"는 애플리케이션의 유저 인터페이스를 표시하는 책임을 지고 있는 컴퍼넌트입니다. 보통 이 UI는 모델 데이터로부터 생성됩니다. (예를 들어, Product 객체의 현재 상태를 표시하는 텍스트박스, 드롭다운, 체크박스를 가지고 있는 Product "수정" 뷰를 만들 수 있습니다.)
- MVC에 기반한 애플리케이션에서 "컨트롤러"는 최종 사용자와의 인터랙션 처리, 모델의 관리, 그리고 UI를 표시하는 데 사용할 뷰를 선택하는 책임을 지고 있는 컴퍼넌트입니다. MVC 애플리케이션에서 뷰는 단지 정보를 표시하는 것에 불과합니다. 사용자의 입력과 인터랙션을 처리하고 또 그에 응답하는 것은 컨트롤러입니다.
MVC 방법론을 사용할 때의 한 가지 이점은 애플리케이션 내의 모델과 뷰와 컨트롤러를 명확하게 분리할 수 있다는 것입니다. 모델과 뷰와 컨트롤러를 명확하게 분리하면 애플리케이션의 테스트를 더욱 쉽게 수행할 수 있습니다. 왜냐하면, 서로 다른 애플리케이션 컴퍼넌트 간의 계약이 더욱 명료하게 정의되어 있기 때문입니다. MVC 패턴을 사용하면 테스트 주도 개발 (TDD)에도 도움이 됩니다. 여기서 테스트 주도 개발이란 실제 코드를 작성하기 전에, 새로 작성할 코드의 요구사항을 정의하고 검증하는 자동화된 단위 테스트를 구현하는 것을 의미합니다. 좀 더 자세히 알아볼까요? ASP.NET MVC 프레임웍의 다운로드가 가능하게 되면, 몇 주 안으로 저는 ASP.NET MVC 프레임웍에 대한 좀 더 상세한 튜토리얼 포스트를 작성할 계획입니다. (그 전까지는 저의 Alt.net 프리젠테이션 비디오를 보는 것이 ASP.NET MVC 프레임웍을 배우는 가장 좋은 방법일 것입니다.) 구체적으로는 아래와 같은 내용을 다룰 예정입니다. - ASP.NET MVC 프레임웍을 적용하면 기본적으로 모델/뷰/컨트롤러의 명확한 분리, 테스트 가능성, TDD가 가능합니다. MVC 프레임웍의 모든 핵심 계약은 인터페이스 기반이며 쉽게 목(mock)으로 사용이 가능합니다 (IHttpRequest/IHttpResponse 기반 인터페이스 포함). ASP.NET 프로세스에서 컨트롤러를 실행하지 않아도 애플리케이션의 단위 테스트를 수행할 수 있습니다 (이는 단위 테스트가 좀 더 빨리 수행될 수 있게 합니다). 단위 테스트 프레임웍은 어떠한 것을 사용하더라도 무방합니다 (NUnit, MBUnit, MS Test 등).
- ASP.NET MVC 프레임웍은 확장성이 높고 플러그인이 가능합니다. MVC 프레임웍 내의 모든 것은 쉽게 교체/커스터마이징이 가능하도록 디자인 되었습니다 (예를 들어, 뷰 엔진. 라우팅 정책, 파라미터 직렬화를 직접 구현하여 플러그인 할 수 있습니다.). 또한 ASP.NET MVC 프레임웍은 기존의 의존성 주입이나 IOC 컨테이널 모델 (Windsor, Spring.Net, NHibernate 등)도 지원합니다.
- ASP.NET MVC 프레임웍은 명료한 URL을 가진 애플리케이션을 개발하는 필요한 대단히 강력한 URL 매핑 컴퍼넌트를 제공합니다. 이 때 URL에는 별도의 확장자를 지정할 필요가 없으며, URL은 SEO와 REST에 어울리는 네이밍 패턴을 지원하게끔 설계되었습니다. 예를 들어 보자면, /products/edit/4 라는 URL을 ProductsController 클래스의 "수정" 액션에 매핑한다든지, /Blogs/scottgu/10-10-2007/SomeTopic/ URL을 BlogEngineController 클래스의 "포스트 표시" 액션에 매핑하는 식입니다.
- ASP.NET MVC 프레임웍은 기존의 ASP.NET .ASPX, .ASCX, .Master와 같은 마크업 파일들을 "뷰 템플릿"으로 간주하여 지원합니다 (즉, 중첩된 마스터 페이지, <%= %> 조각, 선언적 서버 컨트롤, 템플릿, 데이터바인딩, 지역화와 같은 ASP.NET 기능이 사용 가능 하다는 이야기입니다.). 하지만, 서버와 인터랙션을 할 때 포스트백 모델을 사용하지는 않습니다. 대신 최종 사용자의 인터랙션은 컨트롤러 클래스로 보내어 집니다. 이를 통해 모델/뷰/컨트롤러의 명확한 분리나 테스트 가능성이 보장됩니다. (또한 이 말은 MVC 기반 뷰에서는 뷰스테이트나 페이지 수명주기가 없다는 말이기도 합니다.)
- ASP.NET MVC 프레임웍은 기존 ASP.NET의 기능들을 완전히 지원합니다. 이에는 폼/윈도우 인증, URL 권한, 멤버쉽/역할, 출력 캐쉬와 데이터 캐쉬, 세션/프로파일 상태 관리, 헬스 모니터링, 구성 시스템, 공급자 아키텍쳐 등이 포함됩니다.
요약 MVC 방법에 따라 웹 애플리케이션을 개발하는 방법을 찾는 중이라면 ASP.NET MVC 프레임웍이 명료하고 편리한 선택이 될 수 있을 것입니다. ASP.NET MVC 프레임웍은 모델/뷰/컨트롤러을 명확히 분리하고 테스트와 TDD을 쉽게 할 수 있도록 합니다. MVC를 사용할 때의 이점과 그 작동 방법에 대해서는 몇 주 안으로 더 상세한 튜토리얼을 포스팅하도록 하겠습니다. 도움이 되길 바라며, 스캇
|
