2009년 3월 21일 토요일

NHibernate.Linq + ADO.NET DataService

현재 ADO.NET DataServices 가 계속 개발중이라 아직 어떻지는 모르겠지만...

Silverlight를 사용하려면 ADO.NET DataService 를 이용하는 것이 가장 효율적인 방법인 거 같습니다.

알다시피 ADO.NET DataService는 LINQ to SQL, Entity Framework을 한계층 싸서 WCF로 expose해 주는 기능을 합니다.

위의 얘기는 Association이 있는 Persistence graph를 알아서 expose 해준다는 얘기지요...


등을 보면 잘 나와 있습니다.

다만 현재 NHibernate 2.0.1 GA 까지는 NHibernate.Linq 를 공식적으로 지원하지 않기 때문에
그림에 떡입니다.
현재 NHibernate.Linq가 NHibernate Contrib 프로젝트에서 개발 중이기는 합니다만... NHibernate 2.1.0 에 맞춰서 제공될 예정이라고는 하지만... MS가 또 어떤 장난을 칠지...


위 예제는 NHiberate, NHibernate.Linq, ADO.DataService, Silverlihgt를 이용한 예제입니다만
아쉽게도 NH 2.1.0 Alpha 버전에서는 작동하지 않습니다.

ADO.NET DataServices의 핵심 클래스인 DataService 가 바뀌어서 T 가 Object 가 System.Data.Linq.DataContext 이거나 System.Data.Objects.ObjectContext 이어야 하네요...

NHibernate.Linq도 많이 바뀌어야 가능할 듯 싶습니다.

NHibernate 2.1.0 Alpha...

NHibernate 2.1.0 Alpha 1이 Release 되었네요...

svn에서는 Alpha2가 진행중이구요...

많은 기능이 추가되고, Upgrade되었습니다.
다만... alpha2는 아직 버그가 많습니다. 특히 SubQueries 쪽은 검토가 아직 안되었나 봅니다....

아직까지는 2.0.1 GA가 가장 안정적인 것 같습니다.

물론 아주 복잡한 query가 아닌 이상에는 2.1.0 도 쓸만합니다.

2009년 3월 20일 금요일

Role, Group & Members

권한 관리부분에서 가장 큰 부분은 Role 에 속한 Actor에 대한 구분입니다.

Application에서 Role은 크게 두가지로 나뉩니다. 
1. 시스템에서 미리 정의한 System Role
2. 시스템 운영에 따른 실행 산출물에 대한 Role (Instance Role)

1번에 해당하는 것이 Administrator, Users, Guest, Process Modeler User 등이 될 것이고,
2번에 해당하는 것이 Process Owner, Project Managers - 둘 다 특정 Resource에 대해 관련있는 Role입니다.

1번은 유한한 갯수 (100개 미만),
2번은 시스템 운영에 따라 100만개도 생길 수 있습니다.

권한 관리부분에서, 특정 리소스에 대한 접근 허용 여부를 검사하기 위해서는 위의 두가지를
나누어서 검사하는 것이 좋습니다. (Instance Role 이 너무 많기 때문에)

우선 접근 검사를 하고자 할 때의 시나리오를 검토하면

1. 접근 대상이 Application의 정적인 Resource라면 System Role 만 가지고 검사하면 됩니다.
2. 접근 대상이 동적인 Instance Resource라면 System Role로 먼저 검사하고,
    다음으로 Instance Resource와 관련 있는 Role에 Actor가 소속되어 있는지만 검사하면 됩니다.

두 가지를 한꺼번에 할 경우에는 상당히 많은 량의 레코드를 검사해야 하지만,
위와 같이 두 단계로 나누게 되면 검사할 양이 상당히 줄어들게 됩니다.

다만 Instance Resource와 Instance Role 의 Association을 관리해야 하는 기능을 추가해야 하지만,
보통 Role name에 "/Resource/Manager", "/Resource/User" 등으로 이름을 사용하고, 
관련 Instance의 Natural Key를 Association 하면, 레코드 수도 줄고, 상당한 량의 작업도 감소 시킬 수 있습니다.



2009년 3월 8일 일요일

Fluent NHibernate

NHibernate xml mapping 파일 만들기가 힘들거나, 어렵나요?
아니면 직관적이지 않나요?

두가지 방법이 있습니다.

1. Castle Project의
ActiveRecord 를 이용해
매핑정보를 Attribute 로 선언하는 DomainModel을 만든다.
2.
Fluent NHibernate 을 이용하여 Mapping 작업을 Class로 구현한다.

요즘 최신 추세는 Fluent NHibernate인거 같습니다만... 개인 취향의 문제인거 같네요.
어쨌든 mapping 설정 작업 자체가 그리 만만한 것이 아니기에 이런 다양한 시도가 이루어지는 것이겠죠.

NHibernate.Search로 작업하기

NHibernate, Lucene.NET, NHibernate.Search를 이용해서 Web Application Contents 에 대해 Full Text 검색 기능을...

Lucene의 highlight 기능까지 한다면 더 좋겠네...

내일부터 NHibernate.Search도 추가해 봐야겠네...

RCL.Data.NH 용 예제 만들때, 추가 기능으로 넣어봐야 겠다.

2009년 3월 1일 일요일

NHibernate elements(), indices() for IDictionary

특정 엔티티에 Map으로 Composite Element가 연결되어 있을 때
예를 들어, 엔티티에 메타데이타 정보가 연결되어 있을 때 다음과 같이 사용합니다.

enterprise.Metadata["key"] = "value";

hbm에서는 map 이고, c#에서는 IDictionary 또는 IDictionary 로 표현합니다.

이때 특정 메타데이타를 가진 모든 엔티티를 조회하기 기능이 필요할 때가 있습니다.

메타데이타 값을 얻는 것은 조인으로 해결하면 되므로 매우 쉽습니다.

from Enterprise ent join ent.MetadataTable meta where meta.Value = :value

를 사용합니다.

그럼 특정 메타데이타 키를 가진 엔티티를 구하는 방법은? .... 이거 해결하느라 하루가 걸렸네요...

index나 key 에 해당하는 예약어가 있는 줄 알았는데 복수로 indices 라고 있네요... 쩝...

from Enterprise ent where :key in indices(ent.MetataTable)

이라고 하면 됩니다.

특정 키와 값을 모두 찾고 싶다면

from Enterprise ent where :meta in elements(ent.MetaTable)

라고 하면 됩니다.