비즈니스 로직 계층에서 데이터 전송 객체를 설계하는 방법

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

문제

DTO

많은 사용자에게 확장하고 싶은 웹 응용 프로그램을 구축하고 있습니다. 또한 웹 서비스를 통해 신뢰할 수있는 제 3 자에게 기능을 노출해야합니다.

LLBLGEN을 사용하여 데이터 액세스 계층을 생성합니다 (SQL Server 2008 사용). 목표는 웹 앱을 DAL의 세부 사항에서 보호하고 물론 DAL을 넘어서 추가 수준의 검증을 제공하는 비즈니스 로직 계층을 구축하는 것입니다. 또한 내가 지금 알 수있는 한, 웹 서비스는 본질적으로 BLL 위의 얇은 래퍼가 될 것입니다.

물론 DAL에는 고유 한 엔티티 객체, 예를 들어 Customerentity, Productentity 등이 있습니다. 그러나 프레젠테이션 계층이 DAL 특정 방법을 포함하고 어셈블리가 DAL 등에 따라 다르므로 프레젠테이션 계층이 이러한 객체에 직접 액세스하는 것을 원하지 않습니다. 따라서 아이디어는 데이터 전송 객체 (DTO)를 만드는 것입니다. 아이디어는 본질적으로 일반적인 오래된 C#/. Net 객체가 될 것이며, 예를 들어 실제로 데이터베이스 테이블 고객이지만 다른 것들 중 어느 것도 없을 것입니다. 따라서 CustomerDTO, ProductDTO 등이있을 것입니다. 기본 DTO 클래스에서 상속 될 것이라고 가정합니다. 나는 llblgen을위한 템플릿으로 이것들을 생성 할 수 있다고 생각하지만 아직 확실하지 않습니다.

따라서 아이디어는 BLL이 이러한 DTO 객체를 수락하고 반환하여 기능을 노출시킬 것입니다. 웹 서비스는이 객체를 사용하는 제 3자를 위해 이러한 객체를 XML로 변환 할 것이라고 생각합니다. 많은 사람들이 .NET을 사용하지 않을 수도 있습니다 (또한 일부는 JSON을 사용하여 웹 앱의 AJAX 호출에서 스크립트를 호출 할 수 있습니다).

나는 이것을 디자인하는 가장 좋은 방법과 정확히 앞으로 나아가는 방법을 확신하지 못한다. 몇 가지 문제는 다음과 같습니다.

1)이를 클라이언트 (프레젠테이션 계층 및 웹 서비스 코드)에 어떻게 노출 해야하는지

나는 이러한 방법을 가지고있는 공개 수업이 하나있을 것이라고 생각하고 있었는데, 모든 전화는 원자가 일 것입니다.

insertdto, 업데이트, Deletedto, GetProducts, GetProductByCustomer 등 ...

그런 다음 클라이언트는 이러한 방법을 호출하고 적절한 인수, 일반적으로 DTO를 전달합니다.

이것은 훌륭하고 실행 가능한 접근 방식입니까?

2)이 방법에서 무엇을 반환해야합니까? 분명히 Get/Fetch 종류의 메소드는 DTO를 반환합니다. 그러나 인서트는 어떻습니까? 서명의 일부는 다음과 같습니다.

InsertDTO(DTO dto)

그러나 삽입 할 때 무엇을 반환해야합니까? 오류를 알리고 싶습니다. 그러나 일부 테이블에는 자동화 된 기본 키를 사용하지만 (일부 테이블에는 자연 키, 특히 다수의 키가 있습니다).

내가 생각한 옵션 중 하나는 결과 클래스였습니다.

class Result
{
    public Exception Error {get; set;}
    public DTO AffectedObject {get; set;}
}

따라서 인서트에서 DTO는 get id (예 : customerdto.customerid) 속성 세트를 가져온 다음이 결과 객체에 넣습니다. 클라이언트는 result.error! = null이면 오류가 있는지 알면 결과에서 ID를 알 수 있습니다.

이것은 좋은 접근법입니까? 한 가지 문제는 그것이 중복되는 많은 데이터를 앞뒤로 전달하는 것처럼 보인다는 것입니다 (단지 ID 일 때). "int newid"속성을 추가하는 것이 일부 인서트에는 그와 같은 자동화 키가 없기 때문에 깨끗할 것이라고 생각하지 않습니다. 또 다른 문제는 웹 서비스가 이것을 잘 처리 할 것이라고 생각하지 않는다는 것입니다. 나는 그들이 파생 된 DTO가 아닌 결과 클래스에서 영향을받는 작업에 대한 기본 DTO를 반환 할 것이라고 생각합니다. 나는 다른 종류의 결과 객체를 많이함으로써 이것을 해결할 수 있다고 생각하지만 (기본 결과에서 파생되어 오류 특성을 상속 할 수 있음) 그다지 깨끗하지는 않습니다.

알았어, 나는 이것이 너무 말차 없기를 바랍니다.

도움이 되었습니까?

해결책

1 : 이는 최고의 단위 테스트 가능한 접근 방식을위한 "저장소"구현에 적합한 표준 접근 방식입니다.

2 : 예외 (WCF 경계에서 BTW에서 "결함"으로 선언해야 함)는 자동으로 상승됩니다. 직접 처리 할 필요가 없습니다. 데이터의 경우 - 세 가지 일반적인 접근 방식이 있습니다.

  • 사용 ref 계약에서 (아주 예쁘지 않음)
  • (업데이트 된) 개체를 반환합니다 - 즉 public DTO SomeOperation(DTO item);
  • 업데이트 된 ID 정보 만 반환합니다 (기본 키 / 타임 스탬프 / 등)

이 모든 것에 대한 한 가지는 작동 당 다른 유형이 필요하지 않다는 것입니다 (대조 Result 클래스는 DTO에 따라 복제해야합니다).

다른 팁

Q1 :이 문제를 해결하기 위해 WCF 데이터 계약 복합 유형을 DTO로 생각할 수 있습니다. 이런 식으로 UI 계층은 데이터 콘텐츠의 Datamember 속성에만 액세스 할 수 있습니다. 원자 연산은 WCF 인터페이스에 의해 노출 된 메소드입니다.

Q2 : 기본 키 등으로 새로운 사용자 지정 유형을 반환하도록 응답 데이터 계약을 구성합니다 ... WCF는 UI로 다시 기포 예외로 구성 될 수도 있습니다.

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