곧 생성 될 데이터베이스를 시뮬레이트하는 프록시 객체

Question

"위젯"을 포함하는 데이터베이스가 있다고 가정 해 봅시다. 위젯에는 길이 및 너비와 같은 속성이 있습니다 (예 :). wdigets를 작성하기위한 원래의 하위 레벨 API는 엉망입니다. 따라서 더 높은 수준의 함수 세트를 작성하여 호출자가 쉽게 사용할 수 있도록합니다. 데이터베이스가 이상하고 위젯 객체 생성의 타이밍을 잘 제어하지 못합니다. 특히, 특정 다른 일이 먼저 발생한 후에는 처리의 후반 단계까지는 생성 될 수 없습니다. 하지만 내 전화를 으로 보내 주시면 위젯 객체가 초기 단계에서 생성되어 처음부터 해당 속성을 가져 오거나 설정할 수 있다고 생각합니다.

그래서 호출자가 사용할 수있는 "ProxyWidget"객체를 구현했습니다. 그것은 원하는 값을 저장할 수있는 private_Length 및 private_Width와 같은 private 필드가 있습니다. 그런 다음 내 호출자가 액세스 할 수있는 공용 속성 길이 및 너비도 있습니다. 호출자가 폭 속성 값을 설정하는 나에게 말한다 경우, 논리는 다음과 같습니다

• 해당 위젯 개체가 데이터베이스에 이미 존재하는 경우, 는 주어진를 저장,
• 그렇지 않은 경우의 Width 속성 설정 나중에 사용할 수 있도록 private_Width 필드의 너비 값

나중에 일부 위젯 개체가 데이터베이스에 만들어 졌을 때 나는 private_Width에서 데이터베이스 너비 필드로 복사하는 등 모든 값을 복사합니다 (한 필드/속성 한 번에, 불행하게도).

위젯의 한 유형에서 정상적으로 작동합니다. 하지만 약 20 가지 필드/속성을 가진 약 50 가지 유형이 있으며 이로 인해 유지 관리가 쉽지 않습니다. 더 똑똑한 접근법이 있는지 궁금합니다. 아마도 나는 리플렉션을 사용하여 "프록시"객체를 만들고 필드/속성 데이터를 일반적인 방식으로 복사 할 수 있습니다. 반복적 인 코드가 복잡하지는 않습니다. 어떻게 든 공통 코드를 배웁니까? "데이터 바인딩"패턴에서 무엇인가를 배울 수 있습니까? 나는 수학자이지 프로그래머가 아니기 때문에 현재의 접근 방식이 평범한 바보라는 느낌이 들지 않습니다. 내 코드는 C#입니다.

Answer 1

첫째, 내 경험, 수동 이 반복적 인 작업을 많이처럼 느낄 수있는 데이터 액세스 레이어를 코딩 (예 : NHibernate에 또는 엔티티 프레임 워크와 같은 장소에서 ORM, 어느 정도이 문제를 완화 힘을 가하고) 및 레거시 데이터 액세스 계층을 업데이트하는 경우 은 특히 많은 부분으로 구성되어있을 때 끔찍한 작업입니다.

귀하의 질문에 어떤 것이 명확하지 않지만, 여전히 높은 수준의 대답을 줄 수 있다고 생각합니다. 이들은 당신에게 몇 가지 아이디어를 제공하는 것을 목적으로하고있다 :

• 당신은 ProxyWidget을 구축 할 수 있습니다 대안 Widget에 대한 구현 (또는 무엇이든 기존의 낮은 수준의 API에서 위젯 클래스를 호출), 또는 당신이 그것을 구현할 수로 " 위에 "또는"래퍼 주위에 ", Widget. 이것은 Adapter design pattern입니다. 당신이 대신 완전히 분리 Widget 구현을 만드는이 패턴을 사용하는 (여전히 기존의 낮은 수준의 API를 사용하여 코드가 적어도 동안)

  public sealed class ExistingTerribleWidget { … } 
  
  public sealed class ShinyWidget // this is the wrapper that sits on top of the above 
  { 
      public ShinyWidget(ExistingTerribleWidget underlying) { … } 
      private ExistingTerribleWidget underlying; 
      … // perform all real work by delegating to `underlying` as appropriate 
  } 
  

  나는 그것을 추천 할 것입니다 적 데이터베이스 스키마 변경이있는 경우 때문에, 두 개의 서로 다른 API를 업데이트해야합니다. 새 EasyWidget 클래스를 기존 API 위에 래퍼로 ​​빌드하면 변경되지 않고 기본 구현 만 업데이트해야합니다.

• 두 가지 기능이있는 ProxyWidget을 설명합니다. (1) 이미 유지 된 위젯을 수정할 수 있습니다. 그리고 (2) 나중에 데이터베이스에 추가 될 새로운 위젯 용 버퍼. 아직 지속되지 않은 새로운 위젯 하나, 이미 하나의 위젯을 지속 : 당신은 하나 개의 공통 기본 유형과 두 개의 하위 클래스가있는 경우

  당신은 아마도 설계를 단순화 할 수있다.

  interface IWidget { /* define all the properties required for a widget */ } 
  
  interface IWidgetTemplate : IWidget 
  { 
      IPersistedWidget Create(); 
      bool TryLoadFrom(IWidgetRepository repository, out IPersistedWidget matching); 
  } 
  
  interface IPersistedWidget : IWidget 
  { 
      Guid Id { get; } 
      void SaveChanges(); 
  } 
  

  이것은 Builder design pattern 하나의 예이다 : 후자의 하위 유형은 아마도 기존의 위젯이 데이터베이스에 식별로드, 수정, 업데이트 할 수 있도록 별도의 데이터베이스 ID 속성이 있습니다.

• 많은 클래스 (예 : 50 개 이상의 데이터베이스 개체 유형)에 대해 비슷한 코드를 작성해야한다면 T4 text templates을 사용할 수 있습니다. 이것은 코드를 덜 반복적으로 작성하게합니다. 하지만 어딘가에 50 개 이상의 오브젝트를 정의해야합니다.