티스토리 뷰
요즘 참 할일도 많은데 할 수 있는 일이 점점 줄어든다. 필자는 블로그 버킷 리스트(bucket list)를 작성하는데 블로그가 사망하기 전에 꼭 해야 할 일을 목록으로 만들어 놓고 하나 하나씩 글을 써 나간다. 근데 할 일이 늘어만 간다. ㅠ
당장 쓸 수 있는 글 39개
사소한 개발 기술부터 심도있는 내용으로 흐리멍텅한 개념을 글을 쓰면서 잡아 나가는 것들개발 후 산출물로 쓸 글 37개
오픈소스로 내놓을 계획, 또는 알고 있는 것들에 대한 증명이 필요하고 그 후에 쓸 수 있는 글연구개발 11개
배우고 싶은 것, 하고 싶은 것, 해야 하는 것들이고 공부해야 쓸 수 있는 글들
아무튼 점점 쓸 것들이 늘어만 가지만, 하나 하나 하다보면 쓸게 없어 지는 날이 올거라 믿는다 >.,<
#1 - Umc.Core 프레임워크 다이나믹 프록시(Dynamic Proxy)
다이나믹 프록시(Dynamic Proxy)는 최근 IoC(Inversion of Controls)라는 개념으로 확장되고 객체지향 프로그래밍(OOP)의 효율성을 극대화한다. 다이나믹 프록시 기법은 이미 오래 전부터 존재해 왔다.
C++의 스마트 포인터(Smart Pointer) 처럼 직접 포인터를 건들이지 않고 레퍼런스 카운팅이나 객체의 생명주기를 프록시 개체(Proxy Object)를 통해 관리하는 기법이 있고, RPC(Remote Procedure Call)과 같은 원격 프로시저 호출을 위해 프록시 패턴(Proxy Pattern)이 기반에 깔려 직접 원격 구현을 숨기고 간단한 인터페이스만 제공해 주는 패턴 등 매우 다양하다.
최근의 다이나믹 프록시(Dynamic Proxy)는 IoC(Inversion of Control), DI(Dependency Injection), ORM(Object Relation Mapping), AOP(Aspect Oriented Programming) 등 객체를 다루는 프레임워크에서 기본적으로 채용할 만큼 객체를 다룸에 있어 가장 기본적인 기법 또는 기술에 속한다.
필자가 오늘 다루어 볼 내용은 이런 프록시 패턴(Proxy Pattern)이 기반이 되는 개체 제어를 위한 기법이다.
먼저 다이나믹 프록시(Dynamic Proxy)에 대해 예전에 잠깐 쓴 글을 참고하자.
과거 2009년도 닷넷엑스퍼트 재직 시절에 다이나믹 프록시(Dynamic Proxy)를 만들었다가, 2011년 좀 더 나은 객체 디자인으로 완전히 다시 만든 다이나믹 프록시(Dynamic Proxy) 프레임워크가 지금 설명할 Umc.Core.Dynamic.Proxy 이다.
Umc Core 프레임워크는 오픈 소스로 공개되어 있으며 누구든지 소스 코드를 열람할 수 있다. 현재 소스 코드는 다음의 링크를 통해 제공된다.
- 코드 플랙스(CodePlex) - http://umccore.codeplex.com
- github - https://github.com/powerumc
- ***** MY OPEN SOURCE *****.
- [CODEPLEX] POWERUMC.
- [CODEPLEX] Umc Core Frameworks.
- [CODEPLEX] VSGesture.
- [CODEPLEX] jQuery DateTimePicker...
- [CODEPLEX] MEF Generic.
- [CODEPLEX] vutpp for VS2010.
- [CODEPLEX] Unik Project.
- ***** MY TOOLS *****.
- [VSX] VSGesture for VS2005,2008.
- [VSX] VSGesture for VS2010,2012.
- [VSX] Presentaion Mouse Tracker.
- [VSX] Comment Helper for VS2005,2...
- [VSX] VSExplorer for VS2005,2008.
- [VSX] VSCmd for VS2005,2008.
|
|
#2 - 코드부터 보자.
만약 관리 언어(Managed Language)의 동작 매커니즘을 이해하지 못했다면 마치 마법과도 같은 기법으로 보일 것이다. 아래의 코드는 완벽하게 돌아가는 소스 코드이다.
using System;
using Umc.Core.Dynamic;
namespace ConsoleApplication1
{
public interface IPerson
{
string Name { get; set; }
string Email { get; set; }
}
class Program
{
static void Main(string[] args)
{
var type = DynamicProxyObject.InterfaceImplementationType<IPerson>();
var person = (IPerson)Activator.CreateInstance(type);
person.Name = "POWERUMC";
person.Email = "powerumc at 지멜";
Console.WriteLine("Name : {0}, Email : {1}", person.Name, person.Email);
}
}
}
한번 위의 코드를 보자. IPerson 인터페이스는 IPerson을 구현하는 클래스가 반드시 있어야 객체를 생성할 수 있다. 다음과 같이 말이다.
public class Person : IPerson
{
public string Name { get; set; }
public string Email { get; set; }
}
C#의 상식으로 보아도 인터페이스(Interface)는 인스턴스를 생성할 수 없으며, 인스턴스를 생성하기 위해 구현 클래스가 반드시 존재햐여 하는 것 쯤은 알고 있을 것이다. 즉, Person 클래스가 있어야 IPerson person = new Person();
으로 객체를 생성할 수 있다. 분명, 처음 코드의 DynamicProxyObject.InterfaceImplementationType<IPerson>();
가 뭔가의 마법을 부리는 것이 확실하다고 보면 된다.
#3 - 다이나믹 프록시(Dynamic Proxy) 의 다른 구현 방법들
방금 언급한 DynamicProxyObject.InterfaceImplementationType<IPerson>();
코드가 바로 class 로 구현조차 되지 않은 클래스를 동적(Dynamic)으로 런타임에 생성한다. 이 동적 클래스를 런타임에 생성하기 가장 쉬운 방법이 있는데, 그것은 .NET Framework에서 제공하는 CodeDomProvider 이다.
간단히 CodeDomProvider를 언급만 하고 넘어가보자. CodeDomProvider는 C#, VB.NET의 객체 표현을 Code Dom으로 표현할 수 있는데, 각각 CSharp, VB.NET Provider를 제공해 주고, 런타임에 컴파일을 한다. 다만, 컴파일 시간이 동적 객체 생성 기법 중에 가장 느리다.
그리고 C# 3.0부터 지원하는 람다 표현식(Lambda Expression)을 이용하는 방법이다. 이 람다 표현식도 내부적으로 CodeDom과 매우 유사하다. 단점이라면, 객체의 이름(Class Name)과 주소(Namespace) 등을 원하는데로 줄 수 없다. LambdaExpression 클래스의 맴버들이 많은데, 이것들로 모든 구현이 가능하다. 간단한 예제 코드를 보자.
Expression<Func<string, string>> expression = (s) => "Hello " + s;
var func = expression.Compile();
var ret = func("POWERUMC");
Console.WriteLine(ret);
이 코드를 실행하면 “Hello POWERUMC” 라는 결과가 나오는 것을 확인할 수 있다.
이렇게 알게 모르게 이미 .NET Framework에서 다이나믹 프록시(Dynamic Proxy) 기법을 쓰는 곳이 의외로 많다. C# 컴파일러는 익명의 표현식들을 내부적으로 컴파일하면서 메서드로 만들어 버리기도 한다. 이렇게 똑똑한 컴파일러 덕분에 람다 표현식이나 LINQ의 성능이 매우 좋다는 것이다.
이 외에 동적메서드(DynamicMethod) 방법이 있는데, 얘는 그냥 넘어가도 무관하다.
#4 - 다이나믹 프록시(Dynamic Proxy) 개체가 생성되는 일련의 순서
동적 개체가 만들어지려면 어떤 순서가 필요할까?
먼저 객체지향 언어라는 점을 생각해볼때, 객체의 주소(Namespace)와 이름(Type Name)이 필요하다. 필자의 프레임워크 코드 중 Umc.Core.Dynamic.Proxy.Builder 네임스페이스의 ModuleBuilderExtension와 TypeBuilderExtension이 그 역할을 한다.
Type을 생성하기 위해서는 생성자 하나 이상이 반드시 필요한데, Object를 상속하는 타입을 만들어야 한다. 아시다시피 public class Person
클래스는 암묵적으로 public class Person : Object
를 상속하게 된다. 그래서 타입을 생성하고 하나의 생성자를 만들고 나면, 부모 객체인 Object
의 생성자(Constructor)를 호출을 해주어야 한다. 당연히 부모가 있어야 자식이 있는 것과 같다.
이 때 반드시 주의해야 하는 것이 있다. 생성자는 인스턴스를 생성하는 생성자가 있고, static 생성자가 있다. 만약 static 생성자인 경우는 부모 객체인 Object 생성자(Constructor)를 호출하면 안된다.
Object 생성자를 타입의 생성자 안에서 호출하려면 다음과 같은 코드를 이용하면 된다.
il.Emit(OpCodes.Ldarg_0);
l.Emit(OpCodes.Call, typeof(object).GetConstructors([0\]);
이제 IPerson의 프로퍼티(Property)를 구현한다.
IPerson의 프로퍼티 목록은 리플랙션(Reflection)을 이용하여 쉽게 얻어낼 수 있다. 간단히 typeof(IPerson).GetProperties();
면 된다. (프레임워크 내부에선 더 복잡할 수 있음)
C#의 프로퍼티는 컴파일을 하게 되면 프로퍼티가 메서드로 치환된다. 예를 들어, public string Name { get; set; }
코드는 다음 처럼 컴파일러가 치환한다.
public string get_Name() { ... }
public void set_Name(string name) { ... }
그러므로, 다이나믹 프록시를 구현할 때도 프로퍼티를 선언해 준 후에 get, set 메서드를 구현해 주어야 한다. 이를 Umc.Core에서 다음고 같이 구현하였다.
public ICodeLambda Get()
{
var type = new TypeBuilderExtension(null, this.TypeLambda.TypeBuilder);
var methodAttr = this.TypeLambda.MethodAccessor.MethodAttribute | MethodAttributes.NewSlot | MethodAttributes.Final | MethodAttributes.Virtual | MethodAttributes.SpecialName | MethodAttributes.HideBySig;
var method = type.CreateMethod(methodAttr, propertyBuilder.PropertyType, String.Concat("get_", propertyBuilder.Name), Type.EmptyTypes, null, false);
propertyBuilder.SetGetMethod(method);
return new CodeLambda(this.TypeLambda, method.GetILGenerator());
}
public ICodeLambda Set()
{
var type = new TypeBuilderExtension(null, this.TypeLambda.TypeBuilder);
var methodAttr = this.TypeLambda.MethodAccessor.MethodAttribute | MethodAttributes.NewSlot | MethodAttributes.Final | MethodAttributes.Virtual | MethodAttributes.SpecialName | MethodAttributes.HideBySig;
var method = type.CreateMethod(methodAttr, typeof(void), String.Concat("set_", propertyBuilder.Name), new Type[] { propertyBuilder.PropertyType }, null, false);
method.DefineParameter(1, ParameterAttributes.HasDefault, "value");
propertyBuilder.SetSetMethod(method);
return new CodeLambda(this.TypeLambda, method.GetILGenerator());
}
그리고 get, set 메서드의 내부 코드는 다음과 같이 구현된다.
public ITypeLambda GetSet()
{
this.TypeLambda.FieldAccessor.FieldAttribute = FieldAttributes.Private;
var field = this.TypeLambda.Field(this.propertyBuilder.PropertyType, String.Concat("__", propertyBuilder.Name));
var get = this.Get();
{
get.Return(field);
}
var set = this.Set();
{
set.IL.Emit(OpCodes.Ldarg_0);
set.IL.Emit(OpCodes.Ldarg_1);
set.IL.Emit(OpCodes.Stfld, ( (IValuable<FieldBuilder>)field ).Value);
set.Return();
}
return this.TypeLambda;
}
위의 코드가 그 흔한 프로퍼티의 구현부인 public string Name { get { return this._name; } set { this._name = value; } }
를 구현하는 코드가 되겠다. 별거 아닌 코드지만 내부적으로 프로퍼티와 메서드를 생성하고, 그 구현 코드를 IL 코드로 재구현 하면 역시 조금 난이도가 높아진다.
메모리에서 개체 포인터의 엑세스를 방지하기 완료 방법
지금까지는 메모리에 동적인 코드들을 IL 코드들로 구현하였다. 모든 구현이 완료되었으면 더 이상 메모리에서 IL 코드가 위변조 되거나 .NET 코드 정책에 위배되지 않도록 엑세스 접근을 막아야 한다.
이 코드는 Umc.Core.Dynamic.Proxy.Lambda.TypeLambda 클래스의 CreateType() 메서드가 완료시킨다. 이 코드는 다음과 같이 구현 되었다.
public Type ReleaseType()
{
if (this.TypeBuilder == null)
{
throw new NullReferenceException(this.TypeBuilder.GetType().Name);
}
return this.TypeBuilder.CreateType();
}
코드 구현의 완료를 알렸다면 이제 동적 타입(Dynamic Type) 개체가 완성이 된다. 즉, 맨 처럼 IPerson
인터페이스를 구현하는 동적 개체(Dynamic Object)인 Person
개체의 타입이 되는 것이다. 즉, 이 Person
개체는 런타임에서 메모리상에 만들어진 것이 되겠다.
이리하여 Activator.CreateInstance(type)
으로 메모리상에 만들어진 Person
클래스를 생성할 수 있게 되는 것이다.
다이나믹 프록시(Dynamic Proxy) 개체의 모습
메모리상에서 만들어진 Person
개체의 타입은 내부적으로 규칙을 정해서 만들었다. Person
객체를 생성하여 이 객체의 타입을 보면 괴상한 이름으로 지어졌다.
var type = DynamicProxyObject.InterfaceImplementationType<IPerson>();
var person = (IPerson)Activator.CreateInstance(type);
// 결과 -> dynamic_46c8ecaab09b41cbaa814511f69f1974
이 타입이 속한 주소(Namespace)와 모듈(Module)을 직접 디스크에 저장할 수도 있는데, 이런 방법을 이용하여 코드 난독화(Code Obfuscation) 처럼 사용할 수도 있다.
또 다이나믹 프록시(Dynamic Proxy)를 활용해 중간에 로깅(Logging)을 하거나 트랜잭션(Transaction) 처리를 할 수 있는 AOP 를 구현할 수도 있는 것이다. (AOP 구현 기법 중 하나이며, 다른 방법이 더 있다.)
또, 사용 편의성을 위해 고안된 것이 체이닝(Chaining) 방법을 이용하여 런타임 코드를 더 쉽게 만드는 방법을 Umc Core 프레임워크에서 제공한다. 다음의 코드를 보면 쉽게 이해가 될 것이다.
using System;
using System.Linq;
using System.Reflection;
using Umc.Core.Dynamic.Proxy.Lambda;
namespace ConsoleApplication1
{
internal class Program
{
private static void Main(string[] args)
{
string typeName = Guid.NewGuid().ToString("N");
string methodName = Guid.NewGuid().ToString("N");
var assembly = new AssemblyLambda().Assembly();
{
var module = assembly.Module();
{
var type = module.Public.Class(typeName);
{
var constructor1 = type.Public.Constructor();
{
constructor1.Emit.EmitWriteLine("This is constructor");
constructor1.Return();
}
var constructor2 = type.Private.Static.Constructor();
{
constructor2.Emit.EmitWriteLine("This is (private static) constructor");
constructor2.Return();
}
var method = type.Public.Static.Method(methodName);
{
method.Emit.EmitWriteLine("This is emitted writeline");
method.Return();
}
}
var releaseType = type.ReleaseType();
var obj = System.Activator.CreateInstance(releaseType);
var releaseMethod = releaseType.GetMethod(methodName, BindingFlags.Public | BindingFlags.Static);
Console.WriteLine("Release type is {0}", releaseType.AssemblyQualifiedName);
Console.WriteLine("Release method is {0}", releaseMethod.Name);
releaseType.GetMethod(methodName).Invoke(null, null);
Console.WriteLine("".PadLeft(50, '-'));
releaseType.GetMethods().ToList().ForEach(m => Console.WriteLine("Method Name is " + m.Name));
}
}
}
}
}
// 결과 ->
This is (private static) constructor
This is constructor
Release type is bdfd27e5e7ed446d8702fe172733d937, 4a8f6dd24e1f4054b551cca95ad0870b, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
Release method is 389b4a43a1ba4dc1b1391b5b06633645
This is emitted writeline
Method Name is 389b4a43a1ba4dc1b1391b5b06633645
Method Name is ToString
Method Name is Equals
Method Name is GetHashCode
Method Name is GetType
위의 코드와 같이 좀 더 직관적으로 동적 코드를 만드는 방법을 Umc Core에서는 제공해 주고 있다.
재미있는 것은 메서드의 이름이다. 결과 출력 중 Method Name is 389b4a43a1ba4dc1b1391b5b06633645
이 있는데, 놀랍게도 메서드의 이름이 숫자로 시작한다. C# 언어 사양 중 변수의 타입, 변수 등의 이름은 반드시 알파벳 문자로 시작해야 함에도 불구하고, 숫자로 시작하다니…
이는 C#의 언어 사양과 CIL(Common Intermediate Language) 언어의 사양이 다르기 때문이다. 심지어 숫자가 아닌 특수문자로 시작해도 된다. 앞서 말했다시피 이런 방법을 이용하여 코드 난독화(Code Obfuscation) 가 가능하다.
비록 대부분의 Umc Core 소스 코드를 공개하지 않았지만, 미공개 코드 중 코드 난독화 툴도 함께 포함이 되어있고, Junk Assembly를 만드는 툴, AOP based Compile 툴 등도 포함이 되어있다. ㅎㅎㅎ; 아쉽지만 여전히 미공개 분은 공개하지 않을 예정이다. 더불어, 관심있는 독자라면 CIL 언어 스팩의 사양을 살펴보는 것도 좋을 것이다.
결론
지금까지 살펴본 다이나믹 프록시(Dynamic Proxy)를 살펴보았다. 이 기법은 IoC, DI, AOP, ORM 등 최신 객체 제어 기술들의 가장 근간이 되는 기법이다. 여러분들이 최신 기술들로 IoC, DI, AOP 등을 구현하고 싶다면 당장 오픈소스를 이용하면 될 것이다.
아마 필자처럼 .NET 기반으로 다이나믹 프록시(Dynamic Proxy)를 직접 구현해서 쓰는 것은 매우 드문 일이다. 이미 검증된 오픈 소스들도 많기 때문에 굳이 이를 구현해서 쓸 필요는 없다.
하지만 이런 오픈 소스를 이용하여 쓰는 것은 그리 어렵지 않겠지만, 이런 오픈 소스를 이용하여 어떻게 코드를 만드느냐는 성능이나 내부적으로 동작하는 효율성에 영향을 미칠 수 있다. 즉, 자신이 오픈 소스를 이용하여 만든 코드가 효율적인 코드, 그리고 메모리상에서 Clean Code로 동작하느냐는 별개의 문제이다.
필자와 같이 다이나믹 프록시(Dynamic Proxy)를 구현해 보았다면 여러분들이 얼마나 위험한 코드를 많이 만드는지 알 수 있다. 즉, 오픈 소스를 써보기만 했다면 절대로 알 수 없는 고급 기술이다.
ASP.NET MVC 등과 같은 프레임워크에 IoC 등이 통합되면서 내부적으로 이와 유사한 방법을 쓴다. 특히 웹 개발에 있어 IoC와 같은 프레임워크는 굉장히 위험할 수 있다. 설명하자면 지금까지 쓴 내용보다 더 복잡하고 많은 내용으로 설명이 필요할지도 모른다.
만약 관리 언어(Managed Language) 등으로 만들어진(자바도 구현 기법이 유사함) 응용 프로그램의 고성능 튜닝, 트러블 슈팅, .NET 플랫폼에 관심이 많은 독자라면 반드시 이해하고 넘어가야 할 내용들이다. 그리고 오픈 소스를 이용하여 다이나믹 프록시(Dynamic Proxy)를 간접적으로 사용만 한다면 가볍게 읽고 넘어가도 좋다. 소소한 개발 일상의 이야깃 거리도 될 것이다.
필자는 이 외에도 다이나믹 프록시(Dynamic Proxy)를 바탕으로 이를 IoC와 통합하고 AOP, ORM 등을 구현하는 방법도 알아볼 것이다. Umc Core는 오픈 소스로 공개되어 있으며 위키 페이지를 만들겸 하나씩 정리하고자 한다.
- Total
- Today
- Yesterday
- ***** MY SOCIAL *****
- [SOCIAL] 페이스북
- [SOCIAL] 팀 블로그 트위터
- .
- ***** MY OPEN SOURCE *****
- [GITHUB] POWERUMC
- .
- ***** MY PUBLISH *****
- [MSDN] e-Book 백서
- .
- ***** MY TOOLS *****
- [VSX] VSGesture for VS2005,200…
- [VSX] VSGesture for VS2010,201…
- [VSX] Comment Helper for VS200…
- [VSX] VSExplorer for VS2005,20…
- [VSX] VSCmd for VS2005,2008
- .
- ***** MY FAVORITES *****
- MSDN 포럼
- MSDN 라이브러리
- Mono Project
- STEN
- 일본 ATMARKIT
- C++ 빌더 포럼
- .
- Visual Studio 2008
- 팀 파운데이션 서버
- Visual Studio
- POWERUMC
- github
- monodevelop
- 비주얼 스튜디오
- 땡초
- testing
- Visual Studio 11
- .NET
- ASP.NET
- TFS
- Team Foundation Server 2010
- MEF
- Managed Extensibility Framework
- ALM
- test
- Team Foundation Server
- Windows 8
- c#
- LINQ
- 비주얼 스튜디오 2010
- Visual Studio 2010
- mono
- .NET Framework 4.0
- 엄준일
- TFS 2010
- Silverlight
- umc