데이터 액세스 계층에서 비즈니스 계층으로 N-Tier 시스템으로 반환 해야하는 객체

StackOverflow https://stackoverflow.com/questions/518329

문제

예를 들어 Person (ID, Name 등)이라는 데이터베이스 테이블이있는 경우 데이터 액세스 계층이 비즈니스 계층으로 반환 해야하는 객체의 종류는 무엇입니까? 나는 다음과 같이 생각하고있다 :

//data access tier
public class DataAccess{

   public interface IPerson{
      int ID{ get; set; }
      string Name{ get; set; }
   }

   internal class Person : IPerson{
      private int id;
      private string name;

      public int ID{ get{return id; } set{ id=value; } }
      public int Name{ get{retutn name; } set{ name=value; }
   }

   public static IPerson GetPerson(int personId)
   {
      //get person record from db, populate Person object
      return person;  
   }
}

//business tier
public class Person : IPerson{
   private int id;
   private string name;

   public int ID{ get{return id;} set{id=value;} }
   public string Name{ get{return name;} set{name=value;} }

   public void Populate(int personId){
      IPerson temp = DataAccess.GetPerson(personId);
      this.ID = temp.ID;
      this.Name = temp.Name;
   }
}

그러나 이것은 모두 약간 번거로운 것 같습니다. 이 문제에 대한 더 우아한 해결책이 있습니까? 데이터 액세스 계층에서 비즈니스 계층으로 데이터를 반환해야합니까?

도움이 되었습니까?

해결책

DAL (Data Access Layer)에서 클래스 정의를 반복 할 필요가 없습니다.

비즈니스 엔터티를 별도의 어셈블리에서 '멍청한'컨테이너로 만들 수 있습니다. 예를 들어 개인 수업은 다음과 같습니다.

public class Person
{
    int ID { get; set: }
    string Name { get; set: }
}

그런 다음 DAL에 비즈니스 엔티티 계층에 대한 참조를 제공 할 수 있습니다. 컨트롤러 객체는 별도의 비즈니스 로직 계층이든 UI 계층 내에 있든 컨트롤러 객체는 DAL을 호출하여 비즈니스 엔티티를 생성하고 데이터베이스에서 채우고 컨트롤러로 반환 할 수 있습니다.

이 기사 iMar Spaanjaars는이 패턴에 대한 좋은 설명을 가지고 있습니다.

다른 팁

비즈니스 계층은 분명히 데이터 행에 대해 알고 싶지 않습니다. 데이터 계층에 데이터 특정 클래스를 남겨 두십시오. 이렇게하면 커플 링을 줄이고 나중에 도매 재건없이 지속성 층을 변경하도록합니다.

특정 문제를 해결하려면 다음 중 하나가 될 수 있습니다.

  • 데이터 계층에서 기본 데이터 객체/엔티티를 만들고 소비를 위해 비즈니스 계층에 건네주십시오.
  • 또는, 당신이하는 것처럼 보이면, 데이터 계층에서 더 높은 계층에서 비즈니스 객체의 더 풍부한 구현으로 데이터를 전송하는 수단으로 순전히 존재하는 DTO (데이터 전송 객체)를 만듭니다. 리치 도메인 모델에서 저장소 패턴의 일부로이를 수행 할 수 있습니다.

당신이 생각하고 싶은 또 다른 것은 V 층 V 레이어입니다. 이것은 당신이 이러한 것들에 대해 어떻게 생각하는지 차이를 만듭니다. 계층은 일반적으로 물리적이며 즉, 프로세스 간 경계를 정의합니다. 레이어는 일반적으로 논리적이며 프로그램의 기능을 느슨하게 결합 된 단위로 분리합니다. 이 경우 레이어를 목표로하고 있습니다.

DAO 클래스에 대한 인터페이스를 생성하고 비즈니스 계층 내에 배치하는 경우 데이터 액세스 계층에서 비즈니스 계층을 참조 할 수 있습니다. 데이터 계층의 DAO 클래스는 비즈니스 계층에서 객체를 반환합니다.

비즈니스 계층은 데이터 액세스 개체를 직접 참조하는 대신 인터페이스를 참조합니다. IOC 컨테이너 (예 : Castle Windsor)를 통한 의존성 주입을 통해이를 달성 할 수 있습니다.

이 기술은 분리 된 인터페이스라고하며 여기에 설명되어 있습니다.

http://www.martinfowler.com/eaacatalog/separatedinterface.html

내가 본이 기술에 대한 가장 좋은 설명은 Billy McCafferty가 작성한 Nhibernate 모범 사례에 대한이 기사에서 찾을 수 있습니다.

http://www.codeproject.com/kb/architecture/nhibernatebestpractices.aspx

이 기사에는 nhiberbate와 관련된 정보가 많이 있지만, 절반의 좋은 절반은 느슨하게 결합하고 쉽게 테스트 할 응용 프로그램 설계에 대한 확실한 정보 일뿐입니다.

이 규칙으로서 모든 계층이 상단 층으로 느슨하게 결합되어야하는 규칙으로서 DAL에 대한 BL 참조를 추가하는 것은 좋은 생각이 아닙니다. 인터페이스로 DAL의 데이터 모델을 더 잘 정의하고 BL에서 비즈니스 엔티티 양식을 작성합니다. 내 경험으로서, DAL에서 저장소를 사용하고 비즈니스 엔티티 또는 비즈니스 프로세스에서 액세스하는 것이 좋습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top