[지디넷코리아]최근 자바 어노테이션(Annotation)의 등장으로 어트리뷰트 오리엔티드 프로그래밍(attribute oriented programming)에 대한 관심이 많아지고 있다. 하지만 어트리뷰트 오리엔티드 프로그래밍은 어느 날 갑자기 등장한 개념이 아니다. 특히 마이크로소프트(이하 MS) 진영에서는 COM이나 COM+ 개발에서 부분적으로 이미 사용하고 있었으며 닷넷의 경우 어트리뷰티드 프로그래밍이라는 이름으로 초창기부터 지원하고 있던 개념이다.
어트리뷰트 오리엔티드 프로그래밍이란 프로그램 레벨에서의 마킹 기법이다. 이를 사용하면 프로그램을 개발할 때 프로그램과 관련된 메타데이터 정보를 저장하고 이 정보를 이용하여 디자인 타임이나 컴파일 타임, 로딩 또는 런타임 시에 원하는 동작을 수행하도록 할 수 있다.
예를 들면 트랜잭션(Transaction)이라는 어트리뷰트를 선언한 클래스는 클래스의 메소드를 실행할 때 트랜잭션 컨텍스트 내에서 수행되도록 한다. 이러한 기법은 코어 비즈니스 로직과 트랜잭션, 로깅과 같은 횡단 관심사(Cross-cutting concerns)를 분리한다는 점에서 AOP(Aspect Oriented Programming) 기법과 유사하다고 할 수 있다.
어트리뷰티드 프로그래밍 패러다임의 시작
어트리뷰티드 프로그래밍 기법은 COM 기반 프로그래밍에서의 인터페이스 정의 언어(Interface Definition Language)에서 사용되기 시작했다. 라이브러리와 클래스의 uuid나 helpstring같은 프로그램에 대한 메타데이터 값들을 라이브러리나 클래스의 정의에 다음과 같이 선언해 컴파일 시에 참조할 수 있도록 하였다.
[uuid(74731E6F-A0E8-47FB-833C-8D6C75E85981),
helpstring("MessengerAx Control"), control ]
coclass MessengerAx
이러한 기법은 COM+ 기반으로 발전하면서 애플리케이션의 트랜잭션 설정과 풀링, 보안 설정 등의 메타데이터 정보를 구성요소 서비스와 같은 별도의 저장소를 이용해 등록한 후에 이 정보를 런타임 시에 참조해서 프로그램이 동작하도록 하였다.
<화면 1> com+ 트랜잭션 설정 화면
닷넷에서의 어트리뷰티드 프로그래밍 기법은 이보다 한 단계 더 발전된 형태로 사용할 수 있다. 어트리뷰트를 별도의 설정 저장소가 아닌 프로그램 내에 직접 저장할 수 있기 때문이다.
또한 미리 정의된 빌트인(built-in) 어트리뷰트뿐만 아니라 사용자 커스텀 어트리뷰트를 정의하여 사용할 수 있도록 하여 완전한 어트리뷰트 오리엔티드 프로그래밍을 지원하고 있다.
[WebMethod]
public string MyService()
{…}
빌트인(built-in) 어트리뷰트
닷넷에서는 다양한 빌트인 어트리뷰트를 제공한다. 이 중에서 자주 쓰이는 빌트인 어트리뷰트 몇 개에 대해서만 간단히 알아보자. 다른 어트리뷰트에 대해서는 MSDN 등을 참고하길 바란다.
닷넷의 주요 빌트인 어트리뷰티
● System.CLSCompliantAttribute : 프로그램이 CLS(Common Language Specification)을 준수한다고 선언하는 어트리뷰트(CLS는 다양한 언어로 구현된 어셈블리들이 상호 운용하는데 문제가 없도록 하기 위해 지정한 스펙).
● System.EnterpriseServices.TransactionAttribute : 클래스의 트랜잭션을 선언하기 위한 어트리뷰트
● System.ObsoleteAttribute : 해당 메소드나 프로퍼티 등이 더 이상 사용되지 않는다고 선언하는 어트리뷰트
● System.SerializableAttribute : 클래스를 직렬화 할 수 있도록 선언하는 어트리뷰트
● System.Web.Services.WebMethodAttribute : 웹서비스의 메소드가 웹서비스 클라이언트에 의해 호출될 수 있도록 선언하는 어트리뷰트
● System.Web.Services.WebServiceAttribute : 웹서비스의 네임스페이스와 같은 추가 정보를 전달하기 위한 어트리뷰트
● System.Web.Services.WebServiceBindingAttribute : 웹서비스가 지원하는 바인딩 정보를 선언하기 위한 어트리뷰트
● System.Web.Services.Protocols.SoapDocumentMethodAttribute : 웹서비스 바인딩 정보와 웹 메소드를 매핑하기 위한 어트리뷰트
커스텀 어트리뷰트 생성
이제 닷넷의 커스텀 어트리뷰트를 생성하는 방법에 대해서 살펴보자. 닷넷의 어트리뷰트는 System.Attribute 클래스를 상속받은 클래스로 정의한다. 어트리뷰트도 하나의 클래스이기 때문에 생성자나 필드, 메소드 등을 가질 수 있으며 상속도 가능하다. 어트리뷰트 클래스도 일반 클래스처럼 생성자가 없는 경우 디폴트 생성자를 자동으로 생성한다.
<리스트 1>의 어트리뷰트 클래스를 살펴보자. 일반적으로 어트리뷰트명은 Attribute라는 접미어를 가지도록 한다. 어트리뷰트의 정의 부분을 보면 어트리뷰트 클래스에 대한 어트리뷰트로 System.AttributeUsage를 선언한 것을 볼 수 있다.
이 어트리뷰트의 용도는 해당 어트리뷰트를 사용할 수 있는 타깃(예를 들면 클래스, 메소드, 필드, 어셈블리 등)을 지정하고 어트리뷰트의 중복 사용을 허용하거나 어트리뷰트에 대한 상속 허용 등을 지정할 때 사용한다. 어트리뷰트도 클래스이기 때문에 타깃이 클래스인 어트리뷰트들은 어트리뷰트에 선언할 수 있다. AttributeUsageAttribute 클래스도 자기 자신을 어트리뷰트로 선언하여 타깃을 지정하고 있다.
[AttributeUsage(AttributeTargets.Class, Inherited=true)…]
public sealed class AttributeUsageAttribute : Attribute
{…}
<리스트 1>의 예에서는 어트리뷰트를 클래스와 메소드 레벨에서 사용할 수 있도록 지정하였으며 중복을 허용하고 있다. 상속을 지정하지 않는 경우 true 값이 설정된다.
<리스트 1>어트리뷰트 클래스 정의
[System.AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple=true)]
class MyAttribute : Attribute {
private String firstName;
private String lastName;
public MyAttribute(String firstName, String lastName) {
this.firstName = firstName;
this.lastName = lastName;
}
}
class My2Attribute : MyAttribute {
private String middleName;
public String MiddleName {
get { return middleName; }
set { middleName = value; }
}
public My2Attribute() : base("defaultFirstName","defaultLastName") {}
}
어트리뷰트에서 사용할 수 있는 파라미터의 종류는 기본형인 bool이나 char, String 등과 더불어 System.Type과 enum 등도 지원한다.
<리스트1>에서 정의한 어트리뷰트를 사용하는 예를 살펴본다. <리스트 2>와 같이 클래스를 정의한 후에 해당 클래스와 메소드에 ‘MyAttribute’ 어트리뷰트를 선언해 보자. 어트리뷰트 전체 이름(MyAttribute)을 사용해도 되고 어트리뷰트 명에서 Attribute 접미사를 제외한 이름(My)만 사용해도 된다.
어트리뷰트 선언 시에는 어트리뷰트 생성자를 사용하게 된다. 따라서 MyAttribute의 경우 MyAttribute(firstName, lastName)를 호출하게 된다. 생성자의 파라미터 이외의 다른 프로퍼티는 MyAttribute2와 같이 named 기반의 파라미터(MiddleName="K")로 전달한다.
선언의 위치는 일반적으로 대부분의 어트리뷰트는 타깃 타입의 바로 위에 선언하며 어트리뷰트 식별자(Attribute Identifier)를 이용해 어트리뷰트의 적용 대상을 명확히 할 수 있다.
예를 들어 메소드의 리턴 값에 어트리뷰트를 적용하고 싶다면 메소드 위에 선언할 때에는 [return:My2]와 같이 선언하면 된다. 또한 어셈블리에 대한 어트리뷰트의 경우 AssemblyInfo 파일에 [assembly: MyAttribute("DaeWon", "Ryu")]와 같이 선언하면 된다.
<리스트 2>어트리뷰트 사용
[MyAttribute("daewon","ryu")]
[My2Attribute(MiddleName="K")]
public class BizService {
public BizService() {…}
[My2]
public void InsertMethod() { …}
}
<리스트 2>와 같이 어트리뷰트를 선언한 클래스의 메타데이터 정보를 살펴보자. 우선 닷넷 콘솔에서 ILDASM 명령을 통해 MS에서 제공하는 디스어셈블러를 실행한 후에 앞서 생성한 어셈블리 파일을 열어보면 <화면 2>와 같은 클래스 구조 정보를 확인할 수 있다.
<화면 2> ILDASM 화면
ILDASM 애플리케이션의 [View]-[MetaInfo]-[Show!] 메뉴를 선택하면(또는 +) 해당 어셈블리의 메타데이터 정보를 조회할 수 있는 화면이 표시된다.
이 화면 내용을 자세히 살펴보면 <리스트 3>과 같이 BizComp.BizService 클래스에 선언된 커스텀 어트리뷰트 정보와 메소드에 선언된 커스텀 어트리뷰트 정보를 확인할 수 있을 것이다.
이제 메타데이터로 포함된 커스텀 어트리뷰트를 프로그램에서 활용하는 방법에 대해서 살펴볼 차례다. 특정 필드의 길이를 검증하는 예제를 구현해 보도록 하겠다.
우선 C#으로 console application 프로젝트를 하나 생성한다. 프로젝트의 이름은 ValidationTest로 하자.
먼저 사용하려는 어트리뷰트를 추가하기 위해 [추가]-[새로운 아이템]에서 ValidationAttribute 클래스를 추가한다. System.Attribute 추상 클래스를 상속받고 어트리뷰트의 타깃은 필드로 지정한다. 멤버 변수로 int 타입인 minLength, maxLength와 String 타입인 msg(이 필드는 유효성 검사 실패 시 출력할 에러 메시지다)를 추가한다.
그리고 이 멤버 값들을 파라미터로 하는 생성자를 추가한다. 마지막에 인자로 넘어온 minLength와 maxLength의 길이를 비교하여 유효성을 검사하는 IsValid 메소드를 추가한다. 작성된 내용은 <리스트 4>와 같다.
<리스트 4> ValidationAttribute 클래스 소스
[System.AttributeUsage(AttributeTargets.Field, AllowMultiple=true)]
class ValidationAttribute : Attribute {
//필드 및 생성자 생략
public bool IsValid(String data)
{
int lengh = data.Length;
if (lengh >= minLength && lengh < maxLength)
return true;
else return false;
}
}
이제 실제 유효성을 검사하는 클래스를 만들어 보자. [추가]-[새로운 아이템]에서 ValidationCheck 클래스를 추가한다. 이 클래스는 인스턴스화 할 필요가 없으므로 static 클래스로 정의하면 된다. static String CheckValidation(Object data) 메소드를 추가한다.
이 메소드에서는 닷넷의 reflection 기능을 이용해 파라미터로 받은 객체의 타입 정보를 생성한 후 해당 타입으로부터 필드 정보를 읽어오고 필드에 Validation 어트리뷰트가 선언이 되어 있는지 확인한다. 그 결과 Validation 어트리뷰트가 필드의 값이 유효한지를 검사한다. 작성한 결과는 <리스트 5>와 같다.
<리스트 5> ValidationCheck 클래스 소스
public static class ValidationCheck {
public static String CheckValidation(Object data) {
//객체의 타입 정보 조회
Type clsType = data.GetType();
//필드 리스트 조회
FieldInfo [] fields = clsType.GetFields(BindingFlags.Instance | BindingFlags.Public | BindingFlags.GetField| BindingFlags.NonPublic);
bool flag = true;
StringBuilder sbuild = new StringBuilder();
foreach (FieldInfo field in fields) {
//필드의 어트리뷰트 검사
object[] obj = field.GetCustomAttributes(typeof(ValidationTest.ValidationAttribute), true);
if (obj != null && obj.Length > 0) {
ValidationAttribute attr = obj[0] as ValidationTest.ValidationAttribute;
if (attr != null) flag = attr.IsValid(field.GetValue(data).ToString());
if (!flag) sbuild.Append(attr.Msg);
}
}
return sbuild.ToString();
}
}
이번에는 유효성 검사의 대상이 되는 데이터 클래스를 추가해 보자. Program 파일에 MyData라는 클래스를 추가한 후 String 타입으로 firstName, lastName, middleName을 선언한다.
firstName과 lastName에 Validation 어트리뷰트를 선언한 후에 각각의 minLength와 maxLength, error 메시지 값을 부여한다. 결과는 <리스트 6>과 같다.
<리스트 6> Program 클래스 소스
class Program {
static void Main(string[] args) {
MyData data = new MyData("대원", "류", "M");
String msg = ValidationCheck.CheckValidation(data);
Console.WriteLine(msg);
}
}
class MyData {
//생성자 생략
[Validation(1, 5, "이름은 4 자리 이하여야 합니다.")]
String firstName;
[Validation(1, 2, "성은 1자리여야 합니다.")]
String lastName;
String middleName;
}
실행을 시켜 보면 MyData의 firstName과 lastName 값에 대해서 글자 수에 대한 유효성 검사를 실시하는 것을 확인할 수 있다.
어트리뷰트를 사용하지 않는다면 각각의 클래스에 대한 유효성 검사 로직이 클래스에 포함되거나 또는 공통 코드에 각각의 클래스의 경우를 고려해서 추가되어야 한다.
이 유효성 검사의 경우 간단한 예이기 때문에 MyData에서 유효성 검사 로직을 추가해 사용해도 큰 무리가 없겠지만 프로그램이 커질수록 유효성 검사 부분에 대한 부담이 커질 수밖에 없다. 그럼 이제 좀 더 복잡한 내용에 대한 어트리뷰트의 활용법에 대해 알아보자.
어트리뷰트와 리플렉션 에밋(Reflection Emit)을 활용한 프로그램의 확장
특정 어트리뷰트 값을 가지는 경우에 리플렉션 에밋을 이용해서 프로그램을 확장하는 방법에 대해서 살펴보자.
이번에 구현할 내용은 메소드에 Log라는 어트리뷰트가 있는 경우 원래 메소드를 실행하기 전에 로그를 출력하도록 하는 방법에 대해서 테스트 해보도록 하겠다.
C#으로 console application 프로젝트를 하나 생성한다. 프로젝트의 이름은 LoggingTest로 하고, LogAttribute 클래스를 추가한 후에 Attribute를 상속받고 AttributeUsage의 타깃으로 Method를 지정한다. 이 어트리뷰트의 static 메소드로 Print를 선언하고 String 값으로 메소드 명을 받아서 로그를 출력하도록 구현한다.
[AttributeUsage(AttributeTargets.Method)]
public class LogAttribute : Attribute {
public static void Print(String methodInfo) {
Console.WriteLine("Call " + methodInfo);}
}
Program 파일에 인터페이스로 IBizService를 선언한 후에 ProcessData와 ProcessData2를 선언한다. BizService 클래스를 선언하고 ProcessData와 ProcessData2 메소드를 구현한다. Main 메소드에서 IBizService 객체를 생성한 후에 ProcessData를 호출하도록 구현한다. IBizService 객체 생성 시 ServiceLocator를 통해서 생성하도록 한다. 구현 결과는 <리스트 7>과 같다.
<리스트 7> Program 클래스 소스
public class Program {
static void Main(string[] args) {
//ServiceLocator를 통해서 객체 생성
IBizService service = (IBizService)ServiceLocator.getObject("LoggingTest.BizService","LoggingTest.IBizService" );
//Log 어트리뷰트를 사용한 경우
String str = service.ProcessData("my value");
Console.WriteLine(str);
//Log 어트리뷰트를 사용하지 않는 경우
String str2 = service.ProcessData2("my value1","my value2");
Console.WriteLine(str2);}
}
//인터페이스 정의 생략
public class BizService : IBizService {
[Log]
public String ProcessData(string data) {
return data + " has been processed!!!"; }
public String ProcessData2(string data1, String data2) {
return data1 + " and " +data2 + " have been processed!!!"; }
}
ServiceLocator 클래스를 추가한 후에 static 메소드로 GetObject를 생성한다. GetObject의 파라미터로는 타입 명과 인터페이스 명을 받도록 선언한다. 메소드에서는 해당 타입 명과 인터페이스 명을 이용해 객체의 프록시(proxy)를 생성하도록 한다.
이 프록시 객체는 Log 어트리뷰트가 선언되어 있는 경우 리플렉션 에밋을 이용해 로그를 출력하는 코드가 포함된 객체를 생성해 내도록 구현한다.
우선 현재 쓰레드를 이용해 어셈블리 빌더를 생성한 후 모듈 빌더를 생성하고 다시 이 모듈 빌더를 이용해 타입 빌더를 생성한다. 타입 빌더 생성 시 Object 객체를 상속받고 파라미터로 받은 인터페이스 타입을 구현하도록 한다.
메소드 빌더를 이용해 IL 코드를 생성할 수 있는 ILGenerator를 생성한다. 메소드에 Log 어트리뷰트가 선언되어 있는 경우 로그를 출력하는 IL 코드를 삽입한 후에 원래의 메소드를 호출하는 코드를 생성한다.
타입 빌더를 통해 타입을 생성한 후 Activator를 이용해 생성한 객체를 리턴하면 된다. 구현 결과는 <리스트 8>과 같으며 Spring.NET의 AOP 부분이 다음과 같이 리플렉션 에밋을 이용하여 구현되어 있다.
<리스트 8>ServiceLocator 클래스 소스
static class ServiceLocator {
//caching 관련 내용 생략
public static Object getObject(String typeName, String interfaceName) {
//메소드 일부 내용 생략(상세한 내용을 이달의 디스켓 참조)
Type clsType = Type.GetType(typeName);
Type interfaceType = clsType.GetInterface(interfaceName);
MethodInfo[] methodInfos = clsType.GetMethods();
AssemblyBuilder ab = Thread.GetDomain().DefineDynamicAssembly(new AssemblyName("myAsm"), AssemblyBuilderAccess.Run);
ModuleBuilder mb = ab.DefineDynamicModule("myMod");
TypeBuilder tb = mb.DefineType("myType", TypeAttributes.Public | TypeAttributes.Class, typeof(Object), new Type[] { interfaceType });
foreach (MethodInfo methodInfo in methodInfos) {
MethodBuilder methodbuilder = tb.DefineMethod(methodInfo.Name, MethodAttributes.Public | MethodAttributes.Virtual, methodInfo.ReturnType, types);
ILGenerator il = methodbuilder.GetILGenerator();
//Log 어트리뷰트가 선언된 경우 출력을 위한 코드 삽입
object[] myAttributes = methodInfo.GetCustomAttributes(typeof(LoggingTest.LogAttribute), false)
if (myAttributes != null && myAttributes.Length > 0) {
LogInterceptor(methodInfo, il, (Attribute)myAttributes[0]);}
//원래 객체의 메소드를 호출하기 위한 부분
il.Emit(OpCodes.Nop);
il.Emit(OpCodes.Newobj, clsType.GetConstructor(System.Type.EmptyTypes));
for (int i = 1; i <= types.Length; i++) {
il.Emit(OpCodes.Ldarg_S, i); }
il.Emit(OpCodes.Callvirt, methodInfo);
il.Emit(OpCodes.Ret); }
Type t = tb.CreateType();
//객체 생성
Object instance = Activator.CreateInstance(t);
return instance;
}
private static void LogInterceptor(MethodInfo methodInfo, ILGenerator il, Attribute attribute) {
LoggingTest.LogAttribute attr = (LoggingTest.LogAttribute) attribute
il.Emit(OpCodes.Ldstr, methodInfo.Name);
il.Emit(OpCodes.Call, attr.GetType().GetMethod("Print", BindingFlags.Static | BindingFlags.Public)); }
}}
참고로 IL 코드를 생성하는 경우 컴파일 시에 에러에 대한 확인을 할 수 없으며, 런타임 시에도 에러 메시지가 도움이 안되는 경우가 많다. IL 코드를 작성할 때에는 어셈블리를 파일로 저장한 후에(파일에 저장하는 코드는 이달의 디스켓에 주석 처리 되어 있음) 생성된 파일을 reflector와 PEVerify라는 콘솔 명령을 이용해 검사해 보는 방법을 사용한다.
지금까지 어트리뷰트 오리엔티드 프로그래밍 기법을 활용하는 방법에 대해서 살펴보았다. 어트리뷰트는 활용하는 방법에 따라 확장성이 매우 높으며 매우 유용하게 사용될 수 있다. 물론 어트리뷰트 활용 시 리플렉션을 많이 사용하게 되면 오버헤드가 있으므로 적당한 수준에서 사용해야 한다.
이번 칼럼이 독자 여러분에게 어트리뷰트에 대한 이해와 닷넷에서의 적용에 도움이 되었기를 바라면서 이 글을 마친다. @
리플렉션 에밋
일반적으로 리플렉션과 리플렉션 에밋을 혼동하는 경우가 많은데 리플렉션의 용도는 메타데이터나 타입 정보를 조회하거나 동적으로 메소드를 호출하는데 사용이 된다. 반면에 리플렉션 에밋은 런타임 시에 메타데이터와 IL 코드를 생성하거나 물리적인 Portable Executable(PE) 파일로 저장하는 등의 좀 더 강력한 기능이 필요할 때 사용된다.
리플렉션 에밋을 사용하기 위해서는 우선 어셈블리 빌더를 생성해야 하는데 현재 쓰레드의 어플리케이션 도메인을 얻은 후 현재 도메인 객체의 DefineDynamicAssembly 메소드를 호출한다.
메소드의 파라미터로는 어셈블리 명을 지정하는 AssemblyName 객체와 생성된 어셈블리에 대한 실행(Run), 저장(Save) 등의 접근 제어 값인 AssemblyBuilderAccess enum 값을 전달한다.
AssemblyName assemblyName = new AssemblyName("myAssembly");
AssemblyBuilder assemblyBuilder = Thread.GetDomain().DefineDynamicAssembly(assemblyName, AssemblyBuilderAccess.RunAndSave);
생성된 어셈블리 빌더의 DefineDynamicModule을 이용해 모듈 빌더를 생성한다. 파라미터로는 모듈명과 파일로 생성하는 경우 생성할 파일명을 전달한다.
IL 코드를 생성하는 부분에 대해서는 잠시 뒤로 미루고 타입에 대한 작성이 완료가 되면 타입 빌더의 CreateType 메소드를 호출해서 타입을 생성한 후 저장이 필요한 경우 어셈블리 빌더의 Save 메소드를 호출해 저장한다. 주의할 사항은 CreateType 메소드 호출 이후에는 타입에 대한 변경이 불가능하다는 점이다.
Type t = typeBuilder.CreateType();
assemblyBuilder.Save("test.dll");
이제 IL 코드를 작성하는 방법에 대해서 살펴보자. IL 코드를 작성하기 위해서는 IL 이라는 어셈블리와 유사한 언어를 배워야 한다. 물론 어셈블리와 같은 low level 언어를 알아 두는 것도 어떤 면에서는 유용하겠지만 지금 당장 필요하지도 않을뿐더러 향후에도 사용할 이유가 별로 없을 것 같은 언어를 열심히 공부한다는 것은 매우 귀찮은(?) 일이므로 다른 방법을 찾아보자. 본문에서 사용했던 도구인 ildasm을 활용해 보자.
구현하려고 하는 내용을 C#으로 작성한 후 컴파일 된 IL 코드를 조회해 이 코드를 참고해서 우리가 작성하려는 내용에 대한 IL 코드를 작성하면 좀 더 쉽게 구현할 수 있다.
예를 들어 우리가 작성하려는 내용이 <리스트 9>와 같은 코드라고 하면 코드를 컴파일 한 후 ildasm 명령어를 통해 조회해 보면 <리스트 10> 같은 IL 코드 내용을 확인할 수 있겠다.
IL 코드를 살펴보면 첫 번째 파라미터 값을 스택으로 로드한(1) 후 부모 클래스인 Object의 생성자를 호출(2)한다. 두 번째 파라미터인 string 값을 스택에 로드한(4) 후 name이라는 필드에 값을 할당(5)한 후에 리턴(6)한다. 우리가 C# 코드에서 작업해 준 내용은 생성자에서 name 필드에 파라미터로 전달받은 변수를 할당한 것 밖에 없는데 IL 코드에서는 내부적으로 이렇게 상대적으로 많은 코드가 생성이 되는 것이다.
IL 코드 작성 시 주의할 사항은 생성자 작성 시 반드시 부모 클래스의 생성자를 명시적으로 호출해 주어야 한다는 점과 스태틱이 아닌 메소드의 파라미터로 전달되는 값의 첫 번째는 반드시 해당 메소드가 속한 객체에 대한 참조이어야 한다는 점이다. 즉 this 객체에 대한 참조가 되겠다.
<리스트 10>의 생성자 코드를 참고해서 IL 코드를 작성해 보면 <리스트 11>과 같이 된다. ldarg.0 코드는 OpCodes.Ldarg_0과 매핑되고 call 코드는 Opcodes.Call, stfld 코드는 Opcodes.Stsfld와 매핑된다. Opcodes.Call과 Opcodes.Stsfld의 두 번째 파라미터로는 각각 ConstructorInfo, FieldInfo 객체가 되겠다.
FieldInfo 클래스가 FieldBuilder의 부모 클래스이므로 FieldInfo 대신 FieldBuilder 값을 전달한다.
작성된 코드가 정상인지 확인하기 위해서는 어셈블리 파일을 생성한 후에 생성된 어셈블리 파일을 reflector를 이용해 조회해 보면 이상이 없는 경우 정상적으로 디컴파일이 된다.
이상과 같이 리플렉션 에밋에 대한 사용 방법에 대해서 간단히 살펴보았다. 리플렉션 에밋의 경우 리플렉션에 비해서 성능 면이나 확장성 면에서 매우 우수하지만 IL 코드에 대한 작성 부분이 쉽지 않아 많이 사용되지 않고 있다. 하지만 리플렉션 에밋 사용 시 일반적으로 구현하기 힘든 다양한 동적 프로그래밍이 가능하니 기회가 되면 적용해 보길 바란다.
또한 닷넷 2.0에 새롭게 추가된 동적 메소드(Dynamic Method) 기법을 이용하게 되면 어셈블리를 빌드하지 않고도 동적으로 메소드를 호출할 수 있어서 좀 더 향상된 성능 및 유지보수성을 얻을 수 있겠다. 간단한 Dynamic Method 예제는 이달의 디스켓을 참조하기 바란다.
로그인 |
회원가입 (뉴스레터신청) |
SITEMAP
관련기사
독자의견 남기기 (로그인 후 독자 의견을 남기실 수 있습니다.) 
