다층 애플리케이션에서 뷰를 처리하는 방법

Question

저는 프레젠테이션, 비즈니스 및 데이터의 세 가지 레이어가있는 프로젝트를 진행하고 있습니다. 각 레이어는 다른 프로젝트에 있으며 모든 레이어는 다른 프로젝트에 정의 된 DTO를 사용합니다. 비즈니스 계층과 데이터 계층은 데이터베이스를 쿼리 할 때 DTO 또는 DTO 목록을 반환합니다.

지금까지는 좋았지 만 지금은 뷰를 쿼리해야하고 뷰는 기존 DTO와 일치하지 않습니다. 지금까지 우리가 수행 한 작업은 특별한 DTO, 비즈니스 및 데이터 계층 클래스를 생성하여 일반 엔티티 (빼기, 삽입 등 빼기) 처리를 수행하는 것입니다. (삽입, 업데이트 등 빼기)

그러나 올바르게 보이지 않습니다. 그들이 분명히 그렇지 않을 때 정상적인 존재처럼 취급해야하는 이유는 무엇입니까? 음, DTO가 필요해 보이지만, 모든 뷰에 대해 "비즈니스 로직"과 데이터 계층 클래스를 만드는 것은 다소 어색한 것처럼 보입니다. 그래서 모든 뷰에 대한 로직/코드를 포함하는 하나의 일반 비즈니스 및 데이터 계층을 만들었다 고 생각했습니다. (모든 다른 뷰에 대해 DTO를 작성해야하며 아마도 익명 유형을 사용할 수 있습니다.)

나에 관한 아이디어 또는 어떻게이 문제를 해결하겠습니까?

편집 : 9. August 2011 죄송합니다. 해당 게시물이 분명하지 않을 수 있습니다. 조회수는 SQL Server에서 뷰를 의미합니다.

Answer 1

레이어간에 DTO를 사용하지 않는 것이 좋습니다. 나는 어떤 이익이 있다는 것을 확신하지 못하지만, 당신이 생각하는 것이 있으면 기꺼이지도 할 것입니다.

동일한 생각 (비즈니스 개체와 계층 간 여러 DTO)을 표현하는 여러 개의 병렬 계층 구조를 유지하면 해가 발생합니다. 유지 보수하는 데 더 많은 코드가 필요하며 오류 발생 가능성이 커집니다. 여기

내가 응용 프로그램 레이어 줄 방법은 다음과 같습니다

view <--- controller <--- service <--- + <--- model 
             + <--- persistence 

이 디자인은 서비스에서보기를 디커플링을; 다른보기로 서비스를 재사용 할 수 있습니다. 서비스 메소드는 유스 케이스를 구현하고 비즈니스 규칙, 자체 작업 단위 및 트랜잭션에 따라 입력을 검증하고 모델 및 지속성 오브젝트와 협업하여 요청을 수행합니다.

컨트롤러와 뷰가 밀접하게 결합되어 있습니다. 보기를 변경하고 컨트롤러를 변경하십시오. 뷰는 컨트롤러가 제공 한 데이터를 렌더링하는 것 외에는 아무것도 수행하지 않습니다. 컨트롤러는 유효성 검사, 바인딩, 적절한 서비스 선택, 응답 데이터 사용 가능 및 다음보기로 라우팅을 담당합니다.

로깅, 트랜잭션, 보안 등과 같은 교차 절단 문제는 적절한 계층 (일반적으로 서비스)에 적용됩니다.

서비스 및 지속성은 인터페이스 기반이어야합니다.

Answer 2

나는 완전히 당신의 고통을 느낍니다. 실제로 복잡하지 않은 거의 모든 사소한 프로젝트에서 UI를 통해 사용자에게 표시해야하는 항목이 겹치거나 합쳐 지거나 단순히 비즈니스 엔티티 데이터의 하위 집합 일 때가 있습니다. 필자가 접근하는 경향은이 사실을 받아들이고 더 멀리 나아가는 것입니다. 쿼리 측면을 논리적으로나 물리적으로 비즈니스 로직 측면과 분리하십시오. 사실은 실제 비즈니스 운영을 위해서만 귀하의 엔티티가 필요하고 비즈니스 제약 조건을 유효하게 유지해야하며, 언제 이것이 발생합니까? 누군가가 데이터를 변경할 때만. 따라서 데이터를 표시 할 때 엔티티를 작성할 필요가 없습니다.내가 솔루션을 구성하고자 방법은 다음과 같습니다

사용자가보기를 엽니 다 - 당신이 를 호출 할 수 있지만 (> 반환 된 데이터 모델은 -> 쿼리가 뷰의 특정 데이터를 얻을 만 수행 > 컨트롤러 (또는 서비스)의 repo에서 전체 엔티티를 구축 비즈니스 로직 조치가 개체에 수행 - -이 같은 일이이 경우뿐만 아니라 DTO)

사용자가 뭔가를 변경> 변경 이 유지됩니다 - > 결과가 반환됩니다.

내가 말하고자하는 것은, 귀하의 읽기면을 쓰기면과 별도로 다루는 것이 좋습니다. 이것도 다른 인프라를 가지고 있어도 좋습니다. 다르게 처리하기 시작하면 이점을 확인할 수 있습니다. 예를 들어 UI에서 필요한 항목에 맞게 쿼리를 조정할 수 있습니다. 인프라에서 LINQ 또는 일반 SQL 쿼리와 같은 다양한 기술로 쿼리를 작성할 수있는 지점까지 도달 할 수 있습니다. 특정 시나리오에 가장 적합한 것은 무엇입니까?

Answer 3

모든 변환을 관리하는 데 어려움이 많고 지나치게 복잡하므로 이처럼 대부분의 계층화 된 아키텍처를 삭제했습니다. 전형적인 우주 비행사 건축물입니다. 저는 다음을 사용했습니다 :

1. ASP.Net MVC의 폼/뷰 모델보기. 이것은 중요한 디커플링 단계입니다. UI는 일반적으로 모델과는 별도로 진화 할 것입니다.
2. 서비스 계층이 없으며 대신 작은 명령과 쿼리를 나타내는 "명령 처리기"(변형 작업)와 "찾기"(쿼리 작업)로 대체됩니다 (CQS - 명령 쿼리 분리).
3. 모델 내에 NHibernate 및 ALL 도메인 로직이있는 모델 지속성.
4. 외부 서비스는 측정기 및 명령 핸들러 이야기뿐만 아니라

이 낮은 커플 링 매우 평면 관리 아키텍처에 이르게하고 이러한 모든 문제가 사라집니다.