DTO(linq2sql)와 클래스 객체 간의 혼란!

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

문제

나는 linq2sql 및 linq DTO(linq2sql에 의해 생성된 클래스)를 사용하여 성공적으로 작업해 왔습니다....

혼란스럽습니다. 이전 애플리케이션을 업데이트하는 작업이 있는데 내 DTO가 어떻게 사용되어야 하는지 알 수 있습니다....운송 날짜까지

저장소 패턴을 사용하고 있으므로 linq2sql dtos를 통해 저장소에서 서비스로 데이터를 전달하고 있습니다.서비스 계층(기본적으로 내 비즈니스 논리)에 있으면 클래스 개체를 전달해야 합니다.

이러한 클래스 객체는 기본적으로 dtos의 미러 이미지(다소)입니다. 일부 위치에 약간의 변경 사항이 있지만 일반적으로 동일합니다.

그럼 당면한 질문으로 돌아가겠습니다!-- 저장소에서 서비스 계층으로 데이터를 전송하는 데에만 dtos를 사용하는 것이 좋은 방법입니까?서비스 계층(비즈니스 로직)에서는 모든 dto를 클래스 개체 카운터 부분에 매핑해야 합니다(물론 자동 매퍼를 사용합니다!!).

나의 다른 대안은 클래스 객체처럼 DTOS를 계속 사용하고 메서드에서 메서드로, 반환 유형 등으로 전달하는 것입니다. 하지만 이것이 나쁜 습관이라고 생각하고 어떤 메서드를 적용해야 할지 궁금해하면서 계속 원을 그리며 돌아다니고 있습니까?

어떤 도움이라도 정말 감사드립니다.

감사해요

도움이 되었습니까?

해결책

내 의견은 다음과 같습니다.중요하지 않은 응용 프로그램을 다룰 때.linq2Sql 개체를 도메인 모델로 사용하는 것은 정말 나쁜 생각입니다.나는 linq2Sql을 ORM으로 보고 그 이상은 아닙니다.데이터베이스(linq2Sql이 직접적으로 대응하는)는 다음의 정규화입니다. 데이터.클래스(OOAD 의미에서)는 행동 (데이터 아님).

[이 클래스 객체는 기본적으로 미러 이미지입니다.]...

linq2Sql로 애플리케이션을 구축할 때 이런 문제가 발생했습니다.현실적으로 생각해 보겠습니다. 대부분의 LOB(기간 업무) 응용 프로그램은 CRUD 응용 프로그램을 미화하는 것입니다.따라서 애플리케이션 엔터티의 상당 부분이 데이터베이스 테이블에 직접 대응된다는 것은 의심의 여지가 없습니다. 나는 생성된 DTO에 직접 바인딩하고 싶지 않았지만 동시에 내 응용 프로그램 전체에 중복된 클래스가 흩어져 있는 것을 원하지 않았습니다.

내 해결책은 다음과 같습니다.
나는 "인터페이스에 프로그래밍"했습니다.

내가 가지고 있다고 가정 해 봅시다 PersonDto (Dto는 Data Transfer Object를 나타냄)의 속성을 가지고 있습니다. FirstName, LastName, Age (데이터베이스 열과 직접 관련됨)

나는 IPerson 인터페이스를 구현하고 내 PersonD에게 이를 구현하도록 했습니다.


  [Table(Name="Persons")]
  internal class PersonDto : IPerson
  {
      ....
  }

그리고 내 저장소 방법은 가져오고 검색합니다. IPerson Linq2Sql 클래스와 반대입니다.


    IPerson somePerson = _repository.Get(someGuid);
    somePerson.FirstName = "SomeName";
    _repository.Save(somePerson);

이 접근 방식은 나에게 정말 효과적이었습니다.DTO에서 벗어나야 한다고 느낄 때마다 DTO가 아닌 내 개체를 나타내는 인터페이스 덕분에 꽤 쉽게 그렇게 할 수 있습니다.

몇 가지 일반적인 지침:손으로 DTO를 구축하세요. 이상하게 들리겠지만 하향식, 테스트 중심 개발 접근 방식에서 정말 잘 작동한다는 것을 알게 될 것입니다.DTO(linq2Sql) 개체는 매우 가벼우며 .dbml 디자이너 외부에서 변경할 수 있습니다.

DTO 및 DataContext의 내부를 유지하십시오.dto가 공개적으로 노출될 이유가 없습니다(리포지토리 및 도메인 개체에 대한 공개 인터페이스가 있는 경우).이렇게 하면 도메인 모델과 데이터 액세스가 논리적으로 분리됩니다.

모든 데이터 액세스 계층을 별도의 프로젝트에 배치합니다(이 분리를 다시 적용하기 위해).

인터페이스 선언을 별도의 프로젝트에 넣습니다. 이렇게 하면 순환 참조가 발생하지 않습니다.

도움이 되었기를 바랍니다...

다른 팁

내 의도는 약간 다르지만 실제로이 주제에 대해 비슷한 질문을했습니다. 권장 사항은 LINQ2SQL 클래스를 도메인 객체로 사용하고 다른 클래스가 언급 한 바와 같이 부분 클래스를 활용하는 것이 었습니다. 저의 주요 관심사는 해당 객체의 모양 (즉, 속성 이름)과 클래스 멤버의 접근성 (예 : 개인 대 보호)과 관련이 있습니다.

Damien Guard가 T4 템플릿을 모아 LINQ2SQL이 생성 할 클래스의 모양을 제어 할 수 있도록 T4 템플릿을 사용하여 물체의 모양과 접근성을 해결할 수 있습니다. 이것은 여기서 볼 수 있습니다 Linq2SQL 용 T4 템플릿.

이것이 제가 내 우려를 해결하는지 확인하고 볼 접근법입니다. 또한 서비스 계층이 메소드 인수에 대한 인터페이스를 수락 할 수있는 경우 LINQ2SQL DTOS 주변의 인터페이스 랩퍼를 통해 서비스 계층에 액세스 할 수있는 내용을 제어 할 수도 있습니다.

도움이 되었기를 바랍니다.

이것은 내가 본 주제에 대한 가장 좋은 토론 중 하나입니다.

http://blog.wekeroad.com/blog/linqtosql-momma-said-knock-you out/

결국, 커플 링 및 응집력 결정은 상황에 따라 상황에 가장 적합한 것을 결정해야합니다.

응용 프로그램이 LinqTosql을 능가 할 때 LinqToSQL을 잡아 당기고 다른 ORM을 삽입하는 것이 얼마나 쉬운가? 그것은 당신이 진지한 생각을 해야하는 것입니다.

일반적으로 비즈니스 계층이 LINQTOSQL에 대한 지식을 최소화하십시오. LinqToSQL은 UI 계층에 완전히 숨겨져 있어야합니다 (비즈니스 계층은이 방패의 좋은 덩어리를 구성합니다). LinqToSQL로 잘못된 건축 경로를 내리는 것은 매우 쉽고 사실 이후 올바른 길로 돌아 가기가 매우 어려울 수 있습니다.

LINQ2SQL 디자이너가 생성 한 클래스는 부분 클래스이므로이를 확장하고 비즈니스 로직을 직접 넣을 수 있습니다. 아이디어는 LINQ가 이러한 엔티티를 지속/재구성하여 말하는 매핑의 종류를 피할 수 있다는 것입니다.

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