0

데이터베이스의 구성을 저장하고 업데이트해야하는 웹 응용 프로그램에서 작업하고 있습니다. 예를 들어 기본 색상, 언어, 선호 날짜 형식 등과 같은 사용자 기본 설정을 저장할 수 있습니다.이름 값 쌍의 구성 개체

데이터베이스 테이블은 이름/값 쌍 (nvarchars)으로 구성됩니다. 충분히 간단합니다.

저는 ORM을 사용하여 이름/값 문자열 쌍의 목록 (실제로는 IEnumerable)을 가져옵니다. 내 문제는 이러한 IEnumerable을 이름/값 문자열보다 표현력이 풍부한 것으로 변환해야한다는 것입니다. 즉, 강력한 유형의 구성 객체를 만들고 싶습니다.

이상적으로, 나는이 구성 객체가 ORM에 직접적인 의존성을 가지지 않도록하고 싶습니다. 그러나이 객체의 초기화와 영속성 때문에이 작업을 수행하는 방법을 모르겠습니다. 사용자 기본 설정 중 하나만 ORM을 통과해야합니다.

구조 패턴에 어떤 종류의?

(문제가되지해야하지만, 나는 C# 및 엔티티 프레임 워크를 사용하고 있습니다.)


이 편집 :

이의 내가 내 도메인 개체에 다음과 같은 필드가 있다고 가정 해 봅시다 :

public class SettingNameValuePair { 
    public string Name {get;set;} 
    public string Value {get;set;} 
} 

public class GlobalSettings { 
    public System.Drawing.Color FontColor {get;set;} 
    public TimeZoneInfo DefaultTimeZone {get;set;} 
    public DateTime DateCreated {get;set;} 

    ... constructor ... 
    ... validation, other functions ... 
} 

ORM을 설정하여 많은 노력없이 SettingNameValuePair를 가져오고 유지할 수 있습니다. 그러나 어떻게 가져오고 GlobalSettings 유지할 수 있습니까? 즉, 내 응용 프로그램의 어딘가에서 내 전역 설정의 인스턴스를 가져오고 싶습니다.

using (var context = new ApplicationContext()) {  
    GlobalSettings settings = ??? 
} 

ORM은 SettingNameValuePair와 GlobalSettings를 자동으로 변환하는 방법을 알지 못합니다. 내가 GlobalSettings의 강력한 형식의 속성을 생성하기 위해 "배관"코드를 작성해야한다는 것을 알고 있습니다.

내 질문은 : SettingNameValuePair에 의해 채워지는 GlobalSettings의 인스턴스를 다시 얻는 좋은 방법은 무엇입니까? 다음 두 가지 옵션이 틀립니다.

1) GlobalSettings의 생성자가 데이터 컨텍스트를 인수로 사용하도록하십시오. 이로 인해 종속성이 저하되고 테스트하기가 어렵습니다.

using (var context = new ApplicationContext()) {  
    IEnumerable<SettingNameValuePair> nameValuePairs = 
     context.NameValuePairs.ToList(); 
    GlobalSettings settings = new GlobalSettings(nameValuePairs); 
} 

이의 문제는 당신이 사방에이 코드를 반복해야한다는 것입니다 :

2) GlobalSettings의 생성자과 같이 데이터 컨텍스트에서 SettingNameValuePair 년대을 가지고.

싱글 톤, 정적 클래스, 프록시 또는 팩토리 메서드가 포함 된 더 나은 솔루션이 있다는 느낌이 들지만, 아직 이러한 개념에 익숙하지 않습니다.

+0

"이 구성 개체가 ORM에 직접적인 종속성이 없도록 만들고 싶습니다." 도메인 엔터티가 ORM에 의존해서는 안되며 매핑 계층 (orm)이 채울 것입니다. 데이터베이스의 도메인 엔티티 –

+0

@MohamedAbed - 문제를 설명하기 위해 샘플 코드를 추가했습니다. – anonymous

답변

1

도메인 개체에서 ORM을 참조하지 말고 대신 ORM 또는 데이터 액세스 기술을 활용하는 저장소에 구현하십시오 (예 : 대부분의 orms는 키 값 쌍간에 매핑 할 수 없으므로 데이터 판독기). 강하게 타자를 치는 목표).

또한 도메인과 관련된 키 값 쌍을 도메인 객체와 관련이 없으므로 엔티티 (globalsettings)에 키 값 쌍을 생성자로 제공하지 말고 대신 저장소 인 매퍼 계층에 매핑을 구현하십시오 또는 DAL

: 저장소 층에 응용 계층

public GlobalSettings GetUserSettings(User user) 
{ 
    return _globalSettingsRepository.GetGlobalSettings(user); 
} 

에서

public GlobalSettings GetGlobalSettings(User user) 
{ 
    var keyvalue = _context.blablabla(); 
    var globalSettings = new GlobalSettings { Id = keyvalue["key"], DateCreated = DateTime.Parse(keyvalue["datecreated"]) }; 
    return globalSettings 
} 
+0

아. 다양한 이유 때문에 저장소가 없습니다. 이 논리를 쓸 수있는 다른 곳이 있습니까? – anonymous

+0

데이터 액세스 개체 (DAO) 또는 앱 계층의 최악의 경우 –

0

키 - 값 쌍에 매핑되는 ORM이 없다고 생각합니다. 실제로이 데이터에 대해 DataReader를 사용하는 것이 더 효율적일 수 있습니다. 데이터를 가져 왔지만 구성 KVP를 사용하여 사전을 만든 다음 액세스를 위해 Property Pattern을 사용할 수 있습니다. 그런 다음 필요한 속성에 대해 강력한 형식의 접근자를 만들 수 있습니다.이렇게하면 코드를 변경하지 않고 속성을 추가 할 수있는 유연성을 유지하면서도 알고있는 속성에 강력한 형식의 개체를 사용할 수 있습니다.

+0

그건 아주 긴 기사이며, 내 문제와 관련이 있는지 확실하지 않습니다. 내가하려고하는 것을 보여주기 위해 몇 가지 샘플 코드를 추가했습니다. 그것은 멋진 기사처럼 보입니다. – anonymous