2012년 2월 29일 수요일

[책] Thinking In Java 4th Edition

아마 Java 개발자라면 한 권정도는 가지고 있을 바이블에 해당하는 책이라 할 수 있겠죠. 저도 2nd Edition을 소장하고 있고, 이번에 4th Edition을 구매했습니다.

Bruce Eckel 이란 분의 탁월한 사상과 프로그램 언어에 대한 통찰이 돋보이는 책입니다.
개인적으로는 Java 라는 언어도 프로그래밍 언어이므로, 프로그래밍에 대한 기본이 없다면, 어떤 프로그래밍 언어든 어렵기는 매한가지이고, 도구로서 사용하기 어려울 것입니다.

다만, 이 책은 Java 라는 프로그래밍 언어를 통해, Software 프로그래밍에 대한 본질을 잘 설명했다고 평가하고 싶습니다.

이런 통찰력 및 기본적인 이론에 대해 이해하기 쉽고, 자세히 설명한 글은 찾아보기 힘듭니다.

아쉽게도 Thinking in C# 이라는 책도 기획되고, 진행 중이었는데, 중단된 것 같습니다. PDF 형태로 다운로드 할 수는 있습니다만, 중간 중간 집필이 안된 부분이 많군요…

C# 개발자라 하더라도, 차라리 Thinking In Java 번역서를 읽으시면, 더 이해가 잘 될 것입니다. Java 나 C#이나 환경적인 부분은 많이 다르지만, 프로그래밍 언어로서는 크게 다르지 않기 때문에, 기본기를 다지는 데에는 더 없이 좋은 책이라 볼 수 있습니다.

예전에 본 책이지만, 거의 5년여를 Java와는 인연이 없었으니, 다시 보니 새롭네요. 다시 한번 이론 정리도 되구요.

더군다나 Eclipse 도 더 빨라지고, 좋아져서, VS.NET 보다 더 속도감이 있는 건 SSD 때문일까요? 흠…

2012년 2월 27일 월요일

ASP.NET 개발 방향

2012년 1, 2월에 집중적으로 UI 쪽 Framework에 대한 조사 및 공부를 했습니다.

개인적인 소회로는 제가 너무 Background 쪽에만 신경 쓰지 않았나 싶기도 하고, 웹 개발을 담당하고 있는 개발자들은 이런 큰 변화를 받아들이고 있나 싶기도 합니다만,

PMS 팀은 다행히 jQuery 등 JavaScript Framework 을 도입하여, 활용하는 것으로 알고 있습니다.

그럼 제가 2달 동안 공부하면서 느낀 점과 감으로 앞으로의 발전 방향에 대해 의견을 말씀 드리겠습니다.

 

  1. JavaScript Framework 필수 사용 
    1. jQuery, jQuery PlugIn, jQuery UI 사용
    2. Kendo UI 
    3. Ext JS 
    4. jQuery 와 Kendo UI 는 같이 사용할 수 있고, Ext JS 도 같이 사용할 수 있지만, Ext JS 는 워낙 많은 내용이 있어 독립적으로 사용할 수 있습니다.
    5. HTML5, CSS3 를 지원하도록 하는 Plug In이 많이 등장할 것이다. <HtmlDrive>
  2. ASP.NET MVC 득세
    1. Razor Template Engine 도입에 따른 생산성 향상
    2. Unit Testing, IoC/DI 를 통한 제품 안정성 향상 가능 (View 가 없어도 가능)
    3. View 는 Design 쪽에서 개발 가능
    4. MVC용 Javascript Framework Adapter 제공 – Kendo UI, Ext JS 도 MVC 용 라이브러리 제공
  3. ASP.NET WebPages 등장
    1. ASP.NET WebPages 는 Razor Template 엔진을 사용하는 WebForm 이라 보시면 됩니다. 즉 MVC 를 어려워 하거나, 단순한 웹 Application의 경우에는 WebPages 를 이용하여, 쉽고 빠르게 웹 페이지를 개발할 수 있습니다. (WebForm ASP.NET Control을 사용하지 않아 직관적입니다)
    2. 기존 C# 코드를 아주 쉽게 적용할 수 있어 고급 개발도 가능합니다.
    3. Master Page 기능이 있으므로, 기존 디자인 구조를 구조적으로 표현할 수 있습니다.
    4. php 와 유사하고, 간단한 Application 개발에 유용
    5. Helper 를 이용한 확장이 가능

더 많은 기술 자료와 발전 방향이 많겠지만, UI에 한정해서는 위의 방향들이 대세가 아닌가 싶습니다.

제가 초보 개발자라면, 우선 ASP.NET WebPages 의 Razor Template Engine 을 공부하여, 쉽고 빠르게 UI를 만들 수 있는 방법을 습득하고, JavaScript Framework 중 jQuery 와 jQuery PlugIn 들을 사용하는 방법 (특히 ajax) 를 먼저 습득하겠습니다.

중급 이상이라면, Razor, jQuery 정도는 기본으로 깔고, ASP.NET MVC 3, 4 를 심도있게 활용할 수 있도록 IoC/DI 및 ORM 을 연동하고, Unit Testing 및 Web Testing 을 자동 수행할 수 있는 기능을 습득하는 것을 추천드립니다.

그 후 UI에서 가장 화려하고, 기능이 막강한 Ext JS 나 Kendo UI를 도입 (이건 뭐 공부랄 것도 없죠 – 시간이 걸릴 뿐이죠) 하는 겁니다.

사실 저도 Razor Template Engine 이란게 새로 나왔다. 좋다 했을 때는 뭐… 또 금방 사라질 기술을 MS에서 광고 때리는 구나 라고 생각했습니다. 그러나 오판이었습니다. 뭐 자세히 볼 것도 없이, ASP.NET MVC 3 Tutorial Index, ASP.NET MVC 3 Razor 를 보니,

와우… 이거 예전 asp 하고는 완죤 다르네… 상당히 편해졌네… 코드도 지저분해지지 않고…

이게 제가 느낀 점이었습니다. 앞으로 저도 써보면서 처음 느낌이 달라질 수 있겠지만, 지금은 Razor Template Engine은 상당히 괜찮은 물건인 거 같습니다.

2012년 2월 24일 금요일

Razor Template 엔진 활용

기본적으로 Razor template engine 은 MVC  와 WebPages 에서 기존 ASP.NET WebForm Rendering 엔진을 대안으로 작성하기 쉽고, 읽기 용이한 형식을 취한 template engine 이라 할 수 있습니다.

이 template 엔진을 ASP.NET MVC 나 WebPages에서만 사용하기에는 너무 매력적이네요. 제가 보통은 Presentation Layer 가 아닌 서버쪽 프로그래밍을 주로 하다보니, 간이 Template Engine을 활용하여, 대량 메일을 보낸다던가, 서버 상태에 대한 정보를 메신저로 보낸다던가 하는 일을 많이 했습니다.

근데, 이제는 모바일도 지원해야 하고, 간략하면서도 시인성이 좋은 포맷과 화면으로 구성해야 하는데, 굳이 특별한 Template Engine 을 사용하게 되면 결과물의 품질도 낮고, 개발자가 공부하는 것도 힘듭니다.

근데 Razor Template Engine 을 단독으로 사용이 가능하군요. 기존에는 codeplex @razorengine 에서 서비스하다가, 이제는 github 로 옮겼네요. Antaris/RazorEngine 에 가시면 최신 Razor Engine 3.0 Beta를 다운로드 받아 쓰실 수 있습니다.

이제 간단히 Razor Template Engine을 이용하여, Html Template 를 만들고, 변수를 지정해서 결과물을 얻을 수 있네요.

기존의 Template Engine은 따로 공부해야 하지만, Razor 는 HTML, C# 만 알면 작성할 수 있으니 .NET 개발자에게는 가장 좋은 Template Engine이 될 것 같네요^^

2012년 2월 22일 수요일

[책] Test-Drive ASP.NET MVC

아직 다 읽은 건 아니지만, 저자가 개발 환경, 철학, 사용 라이브러리까지 어찌 저랑 그리 비슷한지^^ NHibernate, Castle.Windsor 사용, MVC 가 Castle.MonoRail 에서 발전했다니까, Castle.Windsor 사용은 어찌보면 자연스럽고, 거기다가 NUnit, Rhino Mock 같은 테스트 툴까지도 같네요^^ Resharper 쓰자는 말까지 하다니^^

전 이 책을 TDD 를 위해서 보는 게 아니라, MVC 3 를 공부해서, 제품 하나 만들어 보려고 하는데, MVC 관련 책이 한국에는 없네요… 아마존에 주문해 놓고, 그냥 심심해서 서점 갔더니 이 책이 있어서 그냥 사 봤습니다.

글쓴이의 TDD 에 대한 자세나 여러가지 경험 및 의견에 대해 대부분 동의하고, MVC 에 대한 글도 자세히 설명되어 있어 일석이조가 아닌가 싶습니다.

단 아쉽게도 MVC 2를 기준으로 하여, Razor 를 배우고자 하시는 분은 따로 공부하셔야 합니다. 뭐 Razor 문법 자체는 너무도 간단해서 굳이 책으로 공부할 필요까지는 없을 듯 하더군요… (아직까지는^^)

2012년 2월 21일 화요일

ASP.NET WebPages 란게 뭔가 봤더니…

ASP.NET WebPages 관련 책 한 권을 사서 두 시간 정도에 끝까지 읽어보고… 느낀 점을 써보고자 합니다.

흠… 악평을 하자면… php 짝퉁이라고 할 수 있겠고… Razor 를 포장해서 ASP.NET WebForm 을 약간 변형시킨 게 아닌가 싶네요…
제 경혐 상  Microsoft 사의 초창기 웹 개발 Script 언어인 ASP 를 떠올릴 수 밖에 없겠더군요.
 
Helpers 구조는 좋은 데, 기본적으로 제공하는게 ASP 의 ADO 처럼 Database, Email 관련 Helper 만을 제공하는군요…
왠지… 암울한 생각이 드는 것 같습니다…


그럼 장점을 보자면? Razor 라는 아주 간편하고, 간략히 표현가능한 Template 엔진을 사용하여, 결과 코드의 가독성이 상당히 높다는 점과 Web Form의 Id 값의 자동 생성에 따른 JavaScript Framework 사용의 어려운 점이 사라졌다는 점 등이 있습니다.
또 다른 장점은 .NET 기반이므로, Helpers 나 Functions 를 C# 으로 자체 제작할 수도 있고, 기타 라이브러리리를 참조해서 사용하는 것도 기존 방식과 똑같으니, 어찌보면, Web Form 보다는 제작이 수월할 것으로 예상됩니다.

그동안 제가 Razor 라는 Template 엔진을 좀 오해 했었는데, 이번에 오해를 푼 것이 성과이고, ASP.NET MVC 4 로 개발 시에도 Razor Template 를 사용해야 겠다는 생긱이 듭니다^^

그나저나, 책 쓰신 공저자들끼리, 코딩 규칙도 정하지 않았는지, 챕터마다 코딩 방식이나 규칙도 다 다르고… 특히나 뜽금없이 C# 초보 문법을 왜 넣었는지 의문이더군요… 물론 초보자를 위한 것이였다고 했지만, 차라리 예제 프로젝트 한두개 더를 심도있게 제공하는 것이 좋았을 걸 하는 생각을 해 봅니다.

더 자세한 정보는 : http://www.asp.net/web-pages 를 참고하시기 바랍니다.

2012년 2월 20일 월요일

ASP.NET MVC 가 ASP.NET WebForm 보다 좋은 점

요즘 UI 쪽을 다시 공부하고 있는데, 기존 ASP.NET WinForm 보다 새로운 기능이면서, 빠른 발전을 하고 있는 ASP.NET MVC 3 를 보고 있습니다.  MVC 1, MVC 2 에 비해 MVC 3가 많이 좋아졌고, Razor Template 엔진까지 나왔고… 곧 MVC 4 도 나올 예정이니, 상당히 빠르게 발전하고 있긴 합니다.
사실 전 뭐가 발전하고 있는지, 흐름을 놓친지 하도 오래되어 다시 찬찬히 보고 있는데, 오호라~ 몇 가지 제가 좋아라 하는 기능이 기본적으로 들어 있군요^^
public ActionResult Welcome(string name, int numTimes = 1)
{
    ViewBag.Message = "Hello " + name;
    ViewBag.NumTimes = numTimes;

    return View();
}


Controller 에 다음과 같은 함수를 정의하면,


http://localhost:12095/HelloWorld/Welcome?name=Scott&numTimes=4


과 같이 사용할 수 있군요. 이게 뭐냐구요? 웹 페이지 호출을 함수 호출하듯이 인자가 정의되어 있다는 점 – 즉 Named Parameter 를 사용하여, ASP.NET 의 불명확한 인자에 대한 처리를 명확한 API 형식으로 정의가 가능하다는 점이지요.


또 하나는 ViewBag 이 dynamic 이라 기존 정보 전달에서는 IDictionary<string, object> 가 기본이었는데, 위와 같이 속성처럼 사용이 가능하니, 문자열 타이핑 오류를 상당히 줄일 수 있겠네요^^ 다만, dynamic 속성에 대해서는 refactoring을 지원하지 않는 아쉬움이 있네요.

뭐 저야 화려한 UI를 만드는 역할이 아니라 이런 규격화된 규칙을 정하고, 사용하도록 하는 역할을 수행합니다만. 그 동안 Presentation Layer에 좀 무심했네요.

그리고 얼린 .NET 4 로 올라와야겠군요. 언제까지 .NET 3.5에 머물러 있을 수는 없을 듯 하네요.

아직 MVC 에 많은 것을 공부하지 못했지만, 기존 WebForm 방식보다는 제 맘을 끄는 기능이 많군요. Testing 도 그렇고, MVC 자체 패턴도 그렇고…

2012년 2월 19일 일요일

.NET 4 상속 보안 규칙 문제

.NET 4 는  이전 버전보다 보안이 무척 강화되었네요. 특히 기존 .NET 2.0 이나 .NET 3.5 를 기준으로 컴파일된 에셈블리의 경우 문제가 생기는 경우가 잇습니다. 특히 소스가 있어서 .NET 4 로 컴파일해서 사용하려고 할 때 다음과 같은 예외가 발생할 수 있습니다.

'Inheritance security rules violated while overriding member'

이 문제는 사실 두 군데서 경험했는데, Ext.Net 을 .NET 4 로 컴파일 후 사용하려고 할 때, Microsoft Enterprise Library 5.0 을 .NET 4 에서 사용하려고 할 때 였습니다.

아무리 찾아도 이 문제에 대한 해법은 보이지 않더니, 오늘 우연히 찾았습니다. 결론적으로는 위와 같은 문제가 생기는 경우, 보안 규칙을 .NET 3.5 이하 버전을 기준으로 하도록 강제로 낮추는 것입니다.

실제 Enterprise Library 관련 보안 예외에 대한 정보는 여기를 보세요

AssemblyInfo.cs 에 다음의 코드를 추가하세요.

[assembly: SecurityRules(SecurityRuleSet.Level1)]


이 코드는 보안규칙을 Level1 으로 낮추어서, 보안 규칙 예외를 발생시키지 않도록 하는 것입니다.



보안 관련하여 .NET 4 로 마이그레이션이 안되었던 분들은 위의 보안 규칙을 낮춘 다음에 다시 시도해 보시기 바랍니다.

2012년 2월 16일 목요일

ORM (Object Relational Mapping) 을 왜 쓸까?

NHibernate 를 어언 4년 가까이 공부하고, 사용하면서, 처음 접했을 때의 매력(?) 에 대해 곰곰히 생각해 보게 된다. 지금이야 뭐 당연히 ORM을 쓰는게 너무나 당연하고, 왠만한 경우에도 ORM을 사용하고자 하는 관성에 젖어버려… 처음 ORM을 접하는 사람들에게 “ORM 을 공부하시고, 써 보세요. 신세계가 열립니다” 라고 말하는 것 조차 무의미하게 느껴지게 되었습니다. – 매너리즘에 젖어버렸나요?

어쨌든 다시 한번 생각해 봅시다. 아니 처음 접하시는 분들도 왜 남들이 ORM 에 많은 관심을 가지고, 개발하고, 사용하려고 하는지 생각해 봅시다.

여기 글 중에는 Microsoft 계열 즉 .NET 계열 중심으로 설명할 생각입니다. 주제가 NHibnerate 위주로 설명할 것이고, 제 경험도 Microsoft 계열에 많이 치중되어 있었기에 설명하기가 더 편합니다.

본론으로 들어가서, ORM (Object Relational Mapping) 을 쓰는 이유는 뭘까요?  우선 ORM 정의를 보면 쉽게 알 수도 있겠죠?

Object-relational mapping' (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.”

대강 해석하면 “OOP 언어와 데이터를 다루는 RDBMS 와의 상이한 시스템을 매핑하여, 쉽게 데이터 관련 OOP 프로그래밍을 쉽게 하도록 하기 위한 기술이다” 라고 할 수 있겠습니다.

아시다시피 OOP의 class 구조 와 object-graph 는 RDBMS의 table 구조와 relation 으로 표현이 가능합니다. 다만, 이 두 가지 표현 방식에는 상당한 차이점이 있어 매핑을 통해 변환을 해주어야 한다는 점입니다.

즉 서로 다른 두 지역에서 정보 처리 방식이 전혀 다른데, 이를 중간에서 소통하게 해주는 통역기가 있다면, 둘 다 알 필요 없이, 한 지역의 정보 처리 방식만을 알면 됩니다.

그동안 OOP 언어의 현장에서의 많은 실패의 원인이 이런 데이터를 다루는 부분의 생산성의 문제에 기인한 경우가 많았습니다.

그럼 ORM 이 이렇게 통역기 역할을 해주면 뭐가 좋아지는가? 결론부터 말하면, 개발자가 OOPCBD에 의한 개발에만 집중할 수 있고, RDBMS 관련 부분은 아주 쬐금만 고려하면 된다는 점입니다.

.NET 계열의 대표적인 ORM 툴인 NHibernate 의 개발 모토에도 개발에서“95%의 Database 작업을 제거하는 것이다.” 라고 했습니다. 

이 말은 ORM은 OOP 언어나 CBD 개발 방법론에서 Class 나 Component 설계 및 개발에서 이질적인 RDBMS 와 관련된 부분을 최소화하고, 원 제품의 로직 구현에 충실하고자 하는 의도에서 나온 산물이다 라고 말할 수 있습니다.

그럼 실제 ORM 툴을 도입하여 제품을 개발 시에, 개발자들이 어떻게 변화하는 가를 보게 되면, DataSet과 DataTable,  SQL 문을 중심으로 한 Data 와 ASP.NET Control 이나 HTML, JavaScript의 Presentation Layer 만 있는 단순 어플리케이션이 IList<Entity> 와 Repository, Validator, Interceptor 등 OOP의 다양한 기술을 동반한 한층 업그래이드된 제품으로 격상하게 됨을 느낄 수 있습니다.

특히나 RDBMS 를 전혀 몰라도 웹 개발자가 원하는 개발을 수행할 수 있다는 의미는 Data Layer와 Presentation Layer 를 자연스럽게 분리해주고, Role을 명확히 하고, 단위테스트 등 분산 개발이 가능하게 해 주는 부가 혜택도 있습니다. (물론 이 경우는 iBATIS, Dapper 같은 SQL Mapping Tool 도 제공하는 기능입니다)

자 어느정도 ORM을 왜 쓰는지에 대한 제 의견에 공감을 하시는지요? 땡기시는지요?
만약 아직 땡기시지 않는다면 앞으로 구체적으로 NHibernate 의 예를 들어가면서 ORM 의 세계에 빠져보시기 바랍니다.

물론 제가 NHibernate 를 아주 잘하는 건 아니니, 다른 견해에 대해서는 기탄없이 말씀해주시기 바랍니다. 강호에는 숨은 고수가 많으신데, 잘 나타나시질 않더군요…

2012년 2월 15일 수요일

.NET Framework 4.0 의 Named Parameter 기능

하는 짓이 대부분 Data 다루는 일이고, API 만드는 일이라, 많은 양의 인터페이스, 클래스, 메소드 등을 만듭니다.

.NET 3.5 부터인가?  확장 메소드 (Extension Methods) 기능에 인터페이스 + 제너릭을 이용하면, 상당히 편하게 기존 코드를 변형하거나 확장할 수 있어서 좋았습니다.

.NET 4.0 에서 가장 큰 특징은 TPL (Task Parallel Library) 와 Dynamic 입니다만, TPL은 진작에 마스터(?) 했고, Dynamic 은 거의 쓸 일이 없어서 안 쓰고 있었습니다. 거기다가 Named Parameter는 Delphi 시절부터 잘 쓰던 기능인데, C#에서는 이제서야 제공되네요… TPL은 NET 3.5 용이 따로 제공되어, 회사 라이브러리 제작 시에 활용했습니다만, Dynamic 이나 Named Parameter 는 회사 규정 상 .NET 3.5 / .NET 4.0 동시 지원을 하도록 해서, 그림의 떡(?) 이었습니다.

이번에 개인적으로 만드는 라이브러리는 .NET 4.0 이상만을 지원하도록 하면서, Named Parameter 를 사용하기 시작했습니다.

역시 기대대로 정말 편합니다. overloading 줄어들고, interllisense에 기본 값이 나오니, 기존 overloading보다 훨씬 많은 정보를 사용자에게 알려주게 되네요.

특히나 검색용 쿼리를 만들 때, 인자 값을 미리 설정할 수 있어서 좋고, 생성자도 많이 만들 필요 없고^^

protected DocumentReporter() {}
public DocumentReporter(Document document, ActorObject reporter = null)
{
// ...

}


이렇게 하면 document 만 인자로 해서 만들 수 있습니다^^ 


다만 생성자의 경우 기본 생성자인 class A 의 생성자 A() 와 생성자 A(string n=null) 은 사용자 입장에서는 A() 를 호출 하는 것이 A(string n=null) 을 호출 하는 것이므로, A() 를 제거해도 사용자 입장에서는 제대로 작동합니다만, Reflection을 통해 보면, A 수형의 기본 생성자 (인자가 없는 생성자) 가 없다고 나옵니다. 즉 A()와 A(string n=null) 은 겉보기는 같고, 사용자가 사용하기에는 같지만, 수형 자체는 다르다는 점을 주의하셔야 합니다.


뭐 나머지 경우는 크게 문제 될 것 없고, 사용하기도 편합니다. 다만 ValueType에 대해 default 값을 주고 싶은데, 뭘 지정해야 할지 곤란할 때에는, 기존 방식대로 Nullable<T>를 사용하시면 좋습니다.


public QueryOver<Form, Form> BuildQueryOverOfForm(string name = null,
FormKind formKind = FormKind.Unknown,
bool? isEnabled = null,
bool? isVisible = null)



와 같이 bool? 을 사용하면 됩니다.

2012년 2월 10일 금요일

Javascript UI Framework 들…

Mozilla Developer Network Javascript 재입문 을 통해, 그리고 몇 가지 JavaScript 와 jQuery 책을 통해, 그 동안의 오해와 UI 에 대한 지저분한 작업에서 Behavior가 분리되었음을 알게 되고, UI 관련 많은 Framework 이 벌써 많이 존재하고, 활성화 되어 있음에 놀라지 않을 수 없네요… 쩝

어쨌든, 15 가지 Javascript Web UI Library, Framework and Toolkits 자료에 보듯이 상당히 발전된 UI Framewok 이 있네요… jQuery UI 와 YUI (Yahoo! YUI Library) 는 어느 정도 들어봤지요.

아주 예전부터 써보고 싶었던 것은 Ext JS 와 회사에서 구매해서 사용중인 Kendo UI 도 상당히 좋아 보입니다.

그 동안 제가 너무 UI 쪽에 무지했나 보네요… 그냥 ASP.NET Contorl 과 간단한 Ajax 사용만을 했는데, 이건 뭐… 그냥 아주 쉽게 다 되네요… 이로서 웹 서비스와 Client UI 로 나뉘어진 정돈된 Application이 나올 수 있겠군요^^

그나저나 저 많은 UI Framework 중에 어떤 걸 사용해야 좋을까요? 참 저도 난감하더군요…

우선 기본적으로 jQuery UI 와 기타 jQuery 를 기반으로 하는 Plug In 들은 각각 입 맛에 맞는 것을 가져다 쓰면 될 것이고,
그래도 Chart 라던지, 좀 화려하고 복잡한 컨트롤 (위젯) 을 지원하는 Framework 하나 정도는 표준으로 가져가야 될 듯 한데…

jQuery UI vs Kendo UI , Comparision of JavaScript frameworks 같인 비교 자료를 읽어보면서, 지원되는 방식, 컨트롤 등을 고려해서 선정해야 겠습니다.

지금까지는 당연히 Kendo UI 를 선정하겠지만 (회사에서 이미 라이선스를 가지고 있고, Mobile 도 지원되니), Ext JS 도 상당히 관심이 갑니다. 걸리는 점이 사이즈가 좀 크다는 거…, YUI 도 신뢰할 만 하구요…

그래도 다른 Framework들이 jQuery와는 부딪치지 않고, 같이 혼용해서 사용할 수 있어서 좋습니다.

좋은 Framework 선정이 열 개발자의 야근을 줄일 수 있으니, 신중하게 선택해야겠지요^^

2012년 2월 9일 목요일

jQuery 관련 online 자료

요즘 Javascript, jQuery 및 관련 내용을 공부하고 있습니다. 물론 책부터 샀죠^^ 한 네 권 정도 읽었습니다.
그러면서 online 에서도 관련 자료를 찾던 중 이건 뭐 책보다 더 잘된 구성과 설명이 있는 훌륭한 자료들이 정말 많더군요.

등 참 많네요.

역쉬 웹 개발에 관련된 내용이라, 책보다는 on-line 자료가 demo 즉시 볼 수 있어, 이해하기도 쉽네요.
자료를 만들고, 유지하는 분들께 감사와 격려의 박수를 보냅니다^^

2012년 2월 7일 화요일

NHibernate DTO를 AutoMapper로 구현하기

NHibernate 엔티티를 외부에 서비스하기 위해서는 전통적 방식 중에 하나가 DTO (Data Transfer Object) 패턴을 사용하는 것입니다. 물론 다른 ORM도 마찮가지구요.
다만 문제는 NHibernate 의 Association 이 유지되느냐의 문제인데, 유지를 원할 수도 있고, 안 원할 수도 있습니다.


Entity Framework 처럼 WCF DataService를 이용하면, Domain Layer의 모든 정보를 간단하게 외부에 서비스 (노출) 할 수 있습니다. 정말 환상이긴 합니다만, OOP 의 객체 안정성을 위해, 대부분의 정보를 은폐하는 것을 추천하듯이, 있는 그대로 노출하는 것보다 DTO 패턴을 사용하여, 원하는 내용만 서비스(노출) 하는 것을 더 추천하고 싶습니다.

이 예를 DB 간의 Data 공유 시에 Table 들을 OPEN 해주는 것과 VIEW 를 만들어서 제공하는 것은 다른 의미가 있습니다. 실제 Data를 쓸 수 없다하더라도, 구조를 알게되면 보안에 문제가 생기겠죠.
또 한가지 문제점은 서비스마다 VIEW 를 만든다던가, 공통의 큰 VIEW 하나를 만든다면, 유지보수나 성능상에 문제가 큽니다.

여기 NHibernate 엔티티를 DTO로 만들 때, 단순 엔티티가 아니라 Association 된 부분도 같이 자동으로 Mapping 해주는 기능을 가진 AutoMapper 를 사용해 봅시다.

원문 : AutoMapper 의 Nested Mappings

원문을 보시면 아 하시겠지만, NHIbernate의 Lazy Loading 을 위한 Proxy에 대해서도 과연 될까요? 그럼 함 해보지요^^

 

우선 NHibernate 엔티티로서 Parent-Child 를 구성했습니다.

[Serializable]
public class Parent : DataEntityBase<Guid>, IParent
{
public Parent()
{
Id = Guid.NewGuid();
Version = -1;
}

public virtual int Version { get; set; }
public virtual int Age { get; set; }
public virtual string Name { get; set; }
public virtual string Description { get; set; }

private IList<Child> _children;

public virtual IList<Child> Children
{
get { return _children ?? (_children = new List<Child>()); }
protected set { _children = value; }
}

public override int GetHashCode()
{
if(IsSaved)
return base.GetHashCode();

return HashTool.Compute(Id, Version);
}
}


[Serializable]
public class Child : DataEntityBase<Guid>
{
public Child()
{
Id = Guid.NewGuid();
Version = -1;
Name = "Some Child";
}
public Child(string name, Parent parent):this()
{
Name = name;
Parent = parent;
}
public Child(Guid id, string name, Parent parent): this(name, parent)
{
Id = id;
}

public virtual int Version { get; set; }
public virtual string Name { get; set; }
public virtual string Description { get; set; }
public virtual Parent Parent { get; set; }

public override int GetHashCode()
{
return IsSaved ? base.GetHashCode() : HashTool.Compute(Parent, Name);
}
}


============================================================



자 그럼 Parent – Child 에 대응되는 DTO 들을 정의해보면,



[Serializable]
public class ParentDTO : ValueObjectBase
{
public ParentDTO(string name, int age)
{
Name = name;
Age = age;
}

public Guid Id { get; set; }
public string Name { get; set; }
public int Age { get; set; }

private IList<ChildDTO> _children;
public IList<ChildDTO> Children
{
get { return _children ?? (_children = new List<ChildDTO>()); }
set { _children = value; }
}

public override int GetHashCode()
{
return HashTool.Compute(Name);
}
public override string ToString()
{
return string.Format("ParentDTO# Id=[{0}], Name=[{1}], Age=[{2}]", Id, Name, Age);
}
}



[Serializable]
public class ChildDTO : ValueObjectBase
{
public Guid Id { get; set; }
public int Version { get; set; }
public string Name { get; set; }
public string Description { get; set; }
public ParentDTO Parent { get; set; }

public override int GetHashCode()
{
return HashTool.Compute(Id);
}
public override string ToString()
{
return string.Format("ChildDTO# Id=[{0}], Name=[{1}], Description=[{2}], Parent=[{3}]", Id, Name, Description, Parent);
}
}


 



두 매핑 클래스들이 유사하지요? 다만 NHibernate 엔티티들은 DataEntityBase<T>  라는  NHIbernate용 클래스를 상속 받고, DTO 들은 일반 Persistent Object를 나타내는 ValueObjectBase 클래스를 상속받습니다. 그리고 둘 간의 매핑 정보는 양방향 관계를 가지도록 했습니다.



자 그럼 이제 Mapping 이 제대로 되는지 확인해 봅시다.



/// <summary>
///
AutoMapper 를 이용하여, Association 을 가진 엔티티도 DTO로 매핑이 가능합니다.
/// 즉 Parent-Child 를 ParentDTO-ChildDTO 로 매핑이 가능합니다.
/// </summary>
[TestFixture]
public class DtoMappingFixture : NHRepositoryTestFixtureBase
{
#region << logger >>

private static readonly NLog.Logger log = NLog.LogManager.GetCurrentClassLogger();

#endregion

protected override void
OnTestFixtureSetUp()
{
base.OnTestFixtureSetUp();

Mapper.CreateMap<Parent, ParentDTO>();
Mapper.CreateMap<Child, ChildDTO>();
Mapper.AssertConfigurationIsValid();
}

[Test]
public void MapToDto()
{
UnitOfWork.CurrentSession.Clear();

var parent = Repository<Parent>.Get(parentsInDB[0].Id);

Assert.IsNotNull(parent);
Assert.AreEqual(parentsInDB[0].Name, parent.Name);
Assert.AreEqual(2, parentsInDB[0].Children.Count);
Assert.AreEqual(2, parent.Children.Count);

var parentDTO = Mapper.Map<Parent, ParentDTO>(parent);
Assert.IsNotNull(parentDTO);
Assert.AreEqual(parentsInDB[0].Name, parentDTO.Name);
Assert.AreEqual(2, parentDTO.Children.Count);

foreach(var childDto in parentDTO.Children)
Console.WriteLine(childDto);
}
}




보시다시피 NUnit 을 이용하여 테스트 코드를 작성하였습니다.



우선 테스트 시작 시에 OnTestFixtureSetUp()에서 CreateMap 을 이용하여 각각 Parent – ParentDTO, Child – ChildDTO 에 대한 매핑을 정의하고, 매핑이 유효한지 확인 합니다.



이제 엔티티를 로드하고, Mapper.Map 을 통해 Parent 엔티티를 매핑해서 ParentDTO 를 만들었습니다. 단지 그것만 했는데, parentDTO.Children 에 값이 제대로 들어오는군요.



이제 DTO를 이용한 외부 서비스가 상당히 간단해질 것입니다. 물론 WCF DataService용으로 NHibernateDataContext를 만들어도 되지만, 전 DTO 방식이 노가다가 좀 더 들어가서 고생은 되지만, 유연성이나 보안등에서 더 땡기네요^^



울 회사 PMS 팀에서 이거 보면 뒤집어지겠군요^^



PS. Assertion을 해야 하는데, 어제 밤에 갑자기 해보는 바람에 Console.WriteLine 을 써 버렸네요… 여러분은 Assertion을 하세요. 꼭!!!

2012년 2월 5일 일요일

Free .NET Library 중 강력 추천 라이브러리


원본1 : http://qink.net/page/The-Ultimate-List-of-Freely-Available-_NET-Libraries.aspx
원문2 : http://stackoverflow.com/questions/662956/most-useful-free-net-libraries

위 사이트에 보면 상당히 많은 분야에 유명하면서도, 안정적인 라이브러리들을 소개하고 있습니다.
 
특정 분야에는 너무 많은 제품이 있어서 선택하기 어려울 정도입니다^^
언젠가 저도 이런 자료를 정리하려고 해봤는데… 잘 안되네요^^
되도록 개발자가 많이 사용하거나, 타 제품에서 많이 채택한 라이브러리, 현재 활동이 왕성한 라이브러리를 선택하는 것이 좋습니다.
예를 들어 현재 log4net 은 가장 유명한 logging 라이브러리였지만 2009년부터 더 이상 upgrade 가 되지 않고 있습니다. (2012년에 1.2.11 이 나온다고 하긴 하던데) 그래서 전 NLog 로 전향했습니다. .NET 4.0을 지원하고, 속도 또한 더 빨라서 debug 모드에서도 속도 저하가 별로 없었거든요.

이렇듯 많은 제품에 선택하는 방법은 각자 선택기준을 가지고 판단해서 사용하시기 바랍니다.
굳이 같은 분야에 여러 개를 쓸 필요는 없습니다. NUnit 을 쓰는데, xUnit을 쓸 필요는 없습니다.