프로젝트 로직 구현 - 기술
콘텐츠로 건너뛰기

프로젝트 로직 구현

광고

구현 접근 방식 철학

폭포 접근 방식

애플리케이션 구현에 대한 폭포수 접근 방식에서는 디자이너가 최종 사용자 조직의 한 명 이상의 담당자와 상담하고 모든 애플리케이션 사양을 기록해야 합니다. 일반적으로 사양은 최종 사용자가 문서를 쉽게 읽고 이해할 수 있도록 작성된 기능 문서 또는 사용 사례 세트로 제공됩니다.

최종 사용자가 이러한 문서에 서명하면 애플리케이션을 설계하는 기술 설계 팀에서 문서를 수집하여 클래스 모델 다이어그램, 상태 다이어그램, 활동 다이어그램 및 데이터 모델과 같은 다양한 아티팩트를 생성합니다. 이 단계의 목표는 개발자가 필요한 코드를 만드는 데 문제가 없을 정도로 모든 것을 매우 자세하게 작성하는 것입니다. 개발팀과 테스트팀에 공식적으로 설계가 전달됩니다. 배송 후 개발 팀은 코딩을 시작하고 테스트 팀은 사용 사례와 함께 기술 설계를 사용하여 테스트 사례 및 테스트 시나리오를 만듭니다.

개발팀이 코딩을 마친 후 코드는 테스트팀에 전달됩니다. 테스트 팀은 요구 사항과 세부 설계를 기반으로 설계된 테스트를 수행합니다. 모든 문제는 개발팀에서 해결됩니다. 테스트 및 수정 프로세스가 완료되면 승인 테스트를 위해 애플리케이션이 최종 사용자에게 전달됩니다. 최종 사용자는 애플리케이션이 초기 요구 사항을 준수하는지 확인하기 위해 최종 검사를 수행합니다. 승인되면 완제품을 승인하고 프로젝트가 완료됩니다. 개발팀이 코딩을 마친 후 코드는 테스트팀에 전달됩니다.

테스트 팀은 요구 사항과 세부 설계를 기반으로 설계된 테스트를 수행합니다. 모든 문제는 개발팀에서 해결됩니다. 테스트 및 수정 프로세스가 완료되면 승인 테스트를 위해 애플리케이션이 최종 사용자에게 전달됩니다. 최종 사용자는 애플리케이션이 초기 요구 사항을 준수하는지 확인하기 위해 최종 검사를 수행합니다. 승인되면 완제품을 승인하고 프로젝트가 완료됩니다. 개발팀이 코딩을 마친 후 코드는 테스트팀에 전달됩니다. 테스트 팀은 요구 사항과 세부 설계를 기반으로 설계된 테스트를 수행합니다.

 모든 문제는 개발팀에서 해결됩니다. 테스트 및 수정 프로세스가 완료되면 승인 테스트를 위해 애플리케이션이 최종 사용자에게 전달됩니다. 최종 사용자는 애플리케이션이 초기 요구 사항을 준수하는지 확인하기 위해 최종 검사를 수행합니다. 승인되면 완제품을 승인하고 프로젝트가 완료됩니다.

최종 사용자는 애플리케이션이 초기 요구 사항을 준수하는지 확인하기 위해 최종 검사를 수행합니다. 승인되면 완제품을 승인하고 프로젝트가 완료됩니다. 최종 사용자는 애플리케이션이 초기 요구 사항을 준수하는지 확인하기 위해 최종 검사를 수행합니다. 승인되면 완제품을 승인하고 프로젝트가 완료됩니다.

폭포수 접근 방식을 사용할 때 프로젝트는 더 많거나 더 적은 단계를 가질 수 있지만 주요 특징은 매우 공식적인 결과물과 함께 각 단계의 시작과 끝이 매우 형식적이라는 것입니다.

폭포수 접근 방식의 장점은 각 단계를 담당하는 팀의 책임이 더 크다는 것입니다. 무엇을 전달해야 하는지, 언제 전달해야 하는지, 누구에게 전달해야 하는지가 분명합니다. 개발팀이 사용자와 상호 작용할 필요가 없는 경우가 많습니다. 이는 개발을 다른 국가에 아웃소싱할 때 매우 유용할 수 있습니다.

폭포수 접근 방식의 가장 큰 단점은 모든 것이 매우 형식적인 방식으로 구성되는 환경에서는 변화에 대응하는 유연성이 감소한다는 것입니다. 이사도 정리가 필요합니다. 이를 효과적으로 수행하는 회사는 거의 없으며, 이로 인해 간접비가 크게 증가하는 경우가 많습니다. 프로젝트 비용을 관리하기 위해 일부 회사에서는 애플리케이션이 처음 제공될 때까지 요구 사항 변경을 연기하여 최종 사용자의 요구 사항을 충족하지 못하는 애플리케이션을 효과적으로 제공하기도 합니다.

민첩한 개발

오랫동안 진행된 많은 소프트웨어 개발 프로젝트는 예산을 초과하여 제품을 제때에 제공하지 못했습니다. 민첩한 소프트웨어 개발 철학의 전제는 일반적으로 1~4주 동안 지속되는 반복이라는 짧은 시간 내에 소프트웨어를 개발하여 위험을 최소화하는 것입니다. 각 반복은 자체 소형 소프트웨어 프로젝트와 같으며 계획, 요구 사항 분석, 설계, 코딩, 테스트 및 문서화 등 새로운 기능 증분을 릴리스하는 데 필요한 모든 작업을 포함합니다. 반복이 제품 출시를 보장할 만큼 충분한 기능을 추가하지 못할 수도 있지만 민첩한 소프트웨어 프로젝트는 각 반복이 끝날 때마다 새로운 소프트웨어를 출시할 수 있는 것을 목표로 합니다. 각 반복이 끝날 때마다 팀은 프로젝트 우선순위를 재평가합니다.

민첩한 소프트웨어 개발의 목표는 유용한 소프트웨어를 신속하고 지속적으로 제공하여 고객 만족을 달성하는 것입니다. 항상 고객이 필요로 하는 것을 구축하는 것을 목표로 합니다. 요구 사항에 대한 늦은 변경을 반대하기보다는 환영합니다. 변화하는 상황에 정기적으로 적응합니다. 기업가와 개발자 사이에 긴밀하고 일상적인 협력이 있어야 하며, 대면 대화가 최고의 의사소통 형태입니다.

민첩한 소프트웨어 개발의 가장 큰 장점은 변경 사항을 유연하게 처리하고 항상 비즈니스 요구 사항에 따라 제공하는 것을 목표로 한다는 것입니다. 물론 단점은 범위 관리, 계획, 예산 책정의 복잡성이 증가한다는 것입니다. 또 다른 일반적인 위험은 (기술적) 문서에 대한 관심이 제한된다는 것입니다.

증분 개발

증분 소프트웨어 개발은 애자일 개발과 폭포수 개발의 혼합입니다. 애플리케이션은 각 증분을 최종 사용자에게 전달할 수 있도록 점진적으로 설계, 구현 및 테스트됩니다. 마지막 증분이 완료될 때까지 프로젝트는 완료되지 않습니다. 중간 증분을 정의하고 민첩한 개발의 일부 장점을 활용하여 폭포수를 줄이는 것을 목표로 합니다. 이전 증분에 대해 받은 피드백을 기반으로 다음 증분을 전달할 때 조정이 이루어질 수 있습니다. 다음 증분은 새로운 코드와 이전에 제공된 코드에 대한 수정 사항으로 구성될 수 있습니다.

장점은 형식은 그대로 유지되지만 변경 관리가 더 쉬워진다는 것입니다. 애플리케이션을 여러 번 테스트하고 배포하는 비용은 한 번만 수행하는 것보다 높습니다.

프로그램 흐름 제어

프로그램 흐름 제어에 대한 접근 방식을 선택하는 것은 매우 아키텍처적인 작업입니다. 목표는 일단 기능과 코드를 추가하기 시작하면 모든 것이 제자리에 있는 것처럼 보이는 애플리케이션의 청사진을 만드는 것입니다. 고품질 코드를 검토하거나 작성한 적이 있다면 이 원칙을 이해하고 있을 것입니다.

코드 정리

프로그램 흐름 설계의 첫 번째 단계는 코드를 구성하고, 애플리케이션의 계획 또는 개요를 작성하는 데 도움이 되는 일련의 규칙을 설정하는 것입니다. 코드가 하나의 논리적 위치에 위치하므로 유지 관리, 디버깅 및 버그 수정이 더 쉽게 발생합니다. 기초 작업을 완료한 후에는 애플리케이션 논리 구현에 대한 접근 방식을 선택할 수 있습니다.

디자인 패턴은 프로그램 흐름 제어 디자인에서 중요한 역할을 해야 합니다. 수년에 걸쳐 많은 코드가 작성되었으며 반복되는 문제에 대한 많은 솔루션이 설계되었습니다. 이러한 솔루션은 디자인 패턴으로 확립됩니다. 일반적인 소프트웨어 설계 문제에 디자인 패턴을 적용하면 쉽게 인식하고 동료가 구현할 수 있는 솔루션을 만드는 데 도움이 됩니다. 고유한 문제에는 여전히 고유한 솔루션이 필요하지만 디자인 패턴을 사용하여 문제를 해결할 수 있습니다.

프로젝트 만들기

레이어

첫 번째 단계는 논리적 계층을 고려하는 것입니다. 레이어는 레이어와 동일하지 않으며 종종 혼동되거나 심지어 동일한 것으로 간주됩니다.

레이어와 레이어

레이어는 코드에 경계를 만드는 것입니다. 최상위 계층은 하위 계층의 코드에 대한 참조를 가질 수 있지만 계층은 상위 계층의 코드에 대한 참조를 가질 수 없습니다. 계층화는 여러 컴퓨터에 걸쳐 계층을 물리적으로 배포하는 것과 관련이 있습니다. 예를 들어, 3계층 애플리케이션에서 사용자 인터페이스는 데스크톱 컴퓨터에서 실행되도록 설계되고, 애플리케이션 로직은 애플리케이션 서버에서 실행되도록 설계되었으며, 데이터베이스는 데이터베이스 서버에서 실행됩니다. 각 레이어는 여러 레이어로 구성될 수 있습니다.

그림 8-1: 기본 3계층 조직

레이어는 추상화 수준을 나타냅니다. 그림 8-1에 표시된 레이어는 대부분의 애플리케이션에 적용됩니다. 이러한 수준은 세 가지 주요 레이어라고도 하며 여러 가지 다른 이름을 가질 수 있습니다. 일반적으로 프레젠테이션 계층의 코드는 애플리케이션 논리 계층의 서비스를 호출할 수 있지만 애플리케이션 논리 계층은 프레젠테이션 계층의 메서드를 호출하면 안 됩니다. 프레젠테이션 계층은 데이터 액세스 계층을 직접 호출해서는 안 됩니다. 이렇게 하면 애플리케이션 논리 계층에서 구현한 책임을 우회하게 되기 때문입니다. 데이터 액세스 계층은 애플리케이션 논리 계층을 호출해서는 안 됩니다.

레이어는 추상화일 뿐이며 아마도 레이어를 구현하는 가장 쉬운 방법은 프로젝트에 폴더를 만들고 해당 폴더에 코드를 추가하는 것입니다. 더 유용한 접근 방식은 각 레이어를 별도의 프로젝트에 배치하여 별도의 어셈블리를 만드는 것입니다. 응용 프로그램 논리를 라이브러리 어셈블리에 배치하면 Microsoft Visual Studio 또는 NUnit을 사용하여 단위 테스트를 만들어 논리를 테스트할 수 있다는 이점이 있습니다. 또한 각 계층을 배포할 위치를 선택할 때 유연성이 향상됩니다.

물리적 계층

엔터프라이즈 애플리케이션에서는 동일한 논리에 대해 여러 클라이언트가 있어야 합니다. 실제로 응용 프로그램을 엔터프라이즈 응용 프로그램으로 만드는 것은 클라이언트, 응용 프로그램 서버 및 데이터베이스 서버의 세 가지 계층에 배포된다는 것입니다. 회사의 영업 부서에서 만든 Microsoft Office Access 응용 프로그램은 영업 부서에 매우 중요하지만 엔터프라이즈 응용 프로그램을 구성하지 않습니다.

애플리케이션 로직과 데이터 액세스 계층은 애플리케이션 서버에 함께 배포되는 경우가 많습니다. 프로젝트 디자인의 일부는 .NET 또는 웹 원격 서비스를 사용하여 애플리케이션 서버에 액세스할지 선택하는 것입니다. 선택에 관계없이 프레젠테이션 계층에서 원격 서비스에 쉽게 액세스할 수 있도록 몇 가지 코드를 추가하게 됩니다. 웹 서비스를 사용하여 응용 프로그램 서버의 서비스에 액세스하는 경우 Visual Studio .NET이 작업을 수행하고 프록시 코드를 생성하여 자동으로 원격 프록시 패턴 구현을 제공합니다.

레이어에 패턴 추가

세 가지 기본 레이어는 높은 수준의 개요를 제공합니다. 강력한 엔터프라이즈 아키텍처를 만들기 위해 몇 가지 구조적 패턴을 추가해 보겠습니다. 결과는 그림 8-2에 나와 있습니다.

애플리케이션 로직 계층에 중점을 둡니다. 그림 8-2는 애플리케이션 로직에 접근하는 것이 파사드 패턴을 사용하고 있음을 보여줍니다. 파사드는 클래스 라이브러리와 같은 더 큰 코드 본문에 단순화된 인터페이스를 제공하는 객체입니다. Facade는 대부분의 코드가 Facade를 사용하므로 라이브러리의 내부 작업에 대한 외부 코드 종속성을 줄여 시스템 개발에 더 많은 유연성을 허용합니다. 이를 위해 파사드는 세분화된 객체 컬렉션에 대한 대략적인 인터페이스를 제공합니다.

의사결정 흐름

의사결정 흐름이라고도 알려진 프로그램 흐름 제어는 애플리케이션 논리 계층에서 서비스를 디자인하는 방법 또는 이전 단락에서 본 것처럼 Facade에서 메서드를 디자인하는 방법과 관련이 있습니다.

서비스를 구성하는 방법에는 두 가지가 있습니다.

  • 행동지향적
  • 국가 지향

행동 지향적 접근 방식

사용자 작업을 기반으로 서비스를 구성하면 각 서비스가 프레젠테이션 계층의 특정 요청을 처리하는 서비스를 제공하여 애플리케이션 논리를 구현하게 됩니다. 이는 트랜잭션 스크립트 패턴이라고도 합니다. 이 접근 방식은 간단하고 매우 자연스럽기 때문에 인기가 있습니다. 이 접근 방식을 따르는 메서드의 예로는 BookStoreService.AddNewOrder(Order order) 및 BookStoreService.CancelOrder(int orderId)가 있습니다.

작업을 수행하는 데 필요한 논리는 메서드 내에서 매우 순차적으로 구현되므로 읽기가 쉽지만 코드를 재사용하기가 더 어렵습니다. 테이블 모듈 패턴과 같은 추가 디자인 패턴을 사용하면 재사용성을 높이는 데 도움이 될 수 있습니다.

국가 지향적 접근

훨씬 더 상태 지향적인 방식으로 애플리케이션의 결정 흐름을 구현하는 것도 가능합니다. 응용 프로그램 서버에서 제공하는 서비스는 BookStoreService.SaveOrder(주문 순서)와 같이 본질적으로 더 일반적입니다. 이 메소드는 주문 상태를 확인하고 새 주문을 추가할지 아니면 기존 주문을 취소할지 결정합니다.

데이터 구조 프로젝트

데이터 구조를 설계할 때 여러 가지 선택을 해야 합니다. 첫 번째 선택은 데이터 저장 메커니즘이고, 두 번째는 데이터의 사용 목적이며, 세 번째는 버전 관리 요구 사항입니다. 데이터 구조 설계를 보는 세 가지 방법이 있습니다.

  • 서비스 제공 데이터 데이터는 관계형 데이터베이스를 반영합니다.
  • 데이터는 개체에 매핑되어야 하며 서비스는 개체에 대한 액세스를 제공합니다.
  • 서비스에서 제공하는 데이터는 스키마 기반이어야 합니다.

데이터 흐름 구조의 기초로 세 가지 중 하나를 선택하는 것은 설계 프로세스의 초기 단계에서 이루어져야 합니다. 많은 회사에서는 모든 프로젝트에 대해 세 가지 옵션 중 하나를 의무화하는 회사 정책을 가지고 있지만 가능하면 각 프로젝트의 옵션을 재평가하여 현재 프로젝트에 이상적인 접근 방식을 선택해야 합니다.

데이터 스토리지 엔진 선택

애플리케이션을 설계할 때 특정 유형의 데이터 저장소를 설계해야 한다는 것은 의심의 여지가 없습니다. 다음 저장소와 데이터 저장 형식을 사용할 수 있습니다.

  • 기록
  • app.config 파일
  • XML 파일
  • 일반 텍스트 파일
  • 데이터베이스
  • 메시지 큐

각 매장은 고유한 특성을 갖고 있으며 특정 요구 사항에 맞게 맞춤화할 수 있습니다.

데이터 흐름 설계

ADO.NET을 사용한 데이터 흐름

애플리케이션 논리 계층에서 데이터 중심 서비스를 구현할 때 ADO.NET을 사용하여 데이터 흐름을 디자인하게 됩니다. .NET Framework 클래스 라이브러리는 관리 코드에서 데이터를 조작하기 위한 광범위한 API(응용 프로그래밍 인터페이스)를 제공합니다. ADO.NET이라고 하는 API는 System.Data 네임스페이스에서 찾을 수 있습니다. 미디어와 데이터 저장소의 완전한 분리는 ADO.NET의 중요한 디자인 기능입니다. DataSet, DataTable 및 DataRow와 같은 클래스는 데이터를 저장하도록 설계되었지만 데이터의 출처에 대한 정보는 유지하지 않습니다. 이는 데이터 소스에 구애받지 않는 것으로 간주됩니다. SqlConnection, SqlDataAdapter 및 SqlCommand와 같은 별도의 클래스 집합은 데이터 소스에 연결하고, 데이터를 검색하고, DataSet, DataTable 및 DataRow를 채우는 작업을 담당합니다. 이러한 클래스는 System.Data.Sql, System.Data.OleDB, System.Data.Oracle 등과 같은 하위 네임스페이스에 있습니다. 연결하려는 데이터 소스에 따라 올바른 네임스페이스의 클래스를 사용할 수 있으며, 사용 중인 제품의 범위에 따라 이러한 클래스가 제공하는 기능이 더 많거나 적다는 것을 알 수 있습니다.

DataSet은 데이터 소스에 연결되어 있지 않으므로 애플리케이션에서 데이터 흐름을 관리하는 데 매우 성공적으로 사용될 수 있습니다. 그림 8-5는 이 작업을 수행할 때의 데이터 흐름을 보여줍니다.

이 프로젝트를 살펴보고 누군가가 서점에 로그인하여 세 권의 책을 주문했다고 가정해 보겠습니다. 프리젠테이션 레이어는 장바구니 상태를 관리합니다. 고객은 주문할 준비가 되었으며 필요한 모든 데이터를 제공했습니다. 그는 주문을 보내기로 결정했습니다. 웹 페이지는 모든 데이터를 두 개의 DataTable(하나는 주문용, 다른 하나는 주문용)을 포함하는 DataSet으로 변환합니다. 요청에 대한 DataRow를 삽입합니다. 주문 라인에 대해 3개의 DataRow를 삽입합니다. 그런 다음 웹 페이지는 이 데이터를 다시 한 번 사용자에게 표시하고 DataSet에 대한 데이터 바인딩을 제어하며 Are you really? 사용자는 요청을 확인하고 애플리케이션의 논리 계층에 제출합니다. 애플리케이션 로직 계층은 DataSet을 검사하여 모든 필수 필드에 값이 있는지 확인하고 사용자가 US$ 1,000개 이상을 가지고 있는지 확인합니다. 미결제 금액은 00입니다. 모든 것이 정상이면 DataSet은 데이터베이스에 연결되고 DataSet 정보를 기반으로 삽입 명령을 생성하는 데이터 액세스 계층으로 전달됩니다.

이러한 방식으로 DataSet을 사용하는 것은 응용 프로그램을 만들고 Framework 클래스 라이브러리의 강력한 기능과 DataSet에 대한 GridView와 같은 여러 컨트롤에 데이터를 바인딩하는 ASP.NET의 기능을 사용하는 빠르고 효율적인 방법입니다. 단순한 DataSet 개체를 사용하는 대신 Typed DataSet 개체를 사용하고 프레젠테이션 계층과 응용 프로그램 논리 계층에 코드를 구현하여 코딩 경험을 향상시킬 수 있습니다. 이 접근 방식의 장점은 접근 방식의 단점이기도 합니다. 데이터 모델을 조금만 변경한다고 해서 반드시 많은 메서드의 서명을 변경해야 하는 것은 아닙니다. 따라서 유지 관리 측면에서 이는 매우 잘 작동합니다. 프리젠테이션 계층이 반드시 사용자 인터페이스일 필요는 없지만 웹 서비스일 수도 있다는 점을 기억한다면 데이터베이스의 필드 이름을 바꾸기 때문에 DataSet 정의를 수정하는 경우 해당 계약을 보증하는 계약을 수정하는 것입니다. 웹 서비스 상상할 수 있듯이 이로 인해 몇 가지 심각한 문제가 발생할 수 있습니다. 이 시나리오는 프레젠테이션 계층이 단순한 사용자 인터페이스인 경우에 잘 작동하지만 외부 시스템이나 구성 요소에 대한 인터페이스의 경우 애플리케이션의 내부 작업을 숨기고 데이터를 데이터 모델의 직접 복제가 아닌 다른 것으로 변환하고 싶을 것입니다. DTO(데이터 전송 개체)를 만들고 싶을 것입니다.

객체 관계형 매핑을 사용한 데이터 흐름

ADO.NET을 사용한 데이터 흐름은 데이터 흐름 관리에 대한 매우 데이터 중심적인 접근 방식입니다. 데이터와 논리는 별개입니다. 스펙트럼의 다른 측면은 보다 객체 지향적인 접근 방식을 취하는 것입니다. 여기에서는 데이터와 동작을 그룹화하기 위해 클래스가 생성됩니다. 목표는 애플리케이션이 생성된 비즈니스 도메인에서 발견된 데이터와 동작을 모방하는 클래스를 정의하는 것입니다. 결과를 흔히 비즈니스 객체라고 합니다. 애플리케이션을 구성하는 비즈니스 개체의 컬렉션을 도메인 모델이라고 합니다. 일부 개발자는 더 복잡한 논리를 설계하는 데에는 풍부한 도메인 모델이 더 좋다고 주장합니다. 그러한 진술을 증명하거나 반증하는 것은 어렵습니다. 당신에게 선택권이 있고 그것을 결정하는 것은 당신에게 달려 있다는 것을 아십시오.

그림 8-6은 그림 8-5와 유사한 데이터 흐름을 보여줍니다. 단, 개체 관계형 매핑 계층을 추가하고 DataSet 개체를 다른 데이터 매체로 교체했습니다.

이제 이전과 동일한 단계를 수행하십시오. 누군가가 서점에 로그인하여 세 권의 책을 주문했다고 상상해 보십시오. 프리젠테이션 레이어는 장바구니 상태를 관리합니다. 고객은 주문할 준비가 되었으며 필요한 모든 데이터를 제공했습니다. 그는 주문을 보내기로 결정했습니다. 웹 페이지는 모든 데이터를 DTO로 변환하여 하나의 주문과 세 개의 주문 라인에 대한 데이터를 보유하고 필요에 따라 개체를 생성합니다. 웹 페이지는 이 데이터를 다시 한 번 사용자에게 표시하고 ASP.NET 2.0의 ObjectDataSource를 사용하여 DTO에 대한 데이터 바인딩 제어를 수행하며 Are you really? 사용자는 선택을 확인하고 DTO는 애플리케이션의 논리 계층에 제출됩니다. 애플리케이션 논리 계층은 DTO를 세 개의 OrderLine 개체를 포함하는 속성을 가진 Order 유형의 비즈니스 개체로 변환합니다. 주문 방법. 주문을 검증하고 모든 필수 필드에 값이 있는지 확인하기 위해 Validate()가 호출되며, 사용자의 미결제 송장이 R$ 1,000.00 이상인지 여부를 확인하기 위한 검사가 수행됩니다. 이를 위해 주문은 Order.Customer.GetOutstandingBills()를 호출합니다. 모든 것이 정상이면 Order.Save() 메서드가 호출됩니다. 주문은 주문 및 주문 라인이 DataSet의 DataTable에 매핑되는 개체 관계형 매핑 계층에 제출되고 DataSet은 데이터베이스에 연결되고 다음의 정보로부터 삽입 명령을 생성하는 데이터 액세스 계층으로 전달됩니다. 데이터세트. 물론 개체 관계형 매핑이 발생할 수 있는 방법은 많지만 모든 방법에 DataSet으로의 변환이 포함되는 것은 아닙니다. 일부는 삽입 문을 직접 생성하지만 여전히 데이터 액세스 계층을 사용하여 해당 문을 실행합니다.

보시다시피 일부 변형이 발생합니다. 비즈니스 객체는 동작을 구현하고 동작은 변경될 수 있으므로 DTO를 사용해야 합니다. 프리젠테이션 계층에 대한 이러한 변경의 영향을 최소화하려면 데이터를 비즈니스 객체에서 데이터 전송 객체로 변환해야 합니다. Java에서는 데이터 전송 개체를 일반적으로 값 개체라고 합니다.

비즈니스 개체 작업의 가장 큰 장점은 코드를 구성하는 데 실제로 도움이 된다는 것입니다. 복잡한 로직을 되돌아보면 배관 코드가 거의 없기 때문에 일반적으로 읽기가 매우 쉽습니다. 단점은 대부분의 데이터 저장소가 여전히 관계형이며 비즈니스 개체를 관계형 데이터에 매핑하는 것이 매우 복잡해질 수 있다는 것입니다.

스키마 기반 서비스

데이터 흐름 관리와 관련하여 두 가지 반대되는 현상을 살펴보았습니다. 다양한 변형이 가능합니다. 일반적인 것은 데이터 세트가 데이터 저장을 위한 기본 사용자 인터페이스 데이터 지원으로 사용되지만 다른 시스템에서 호출되는 웹 서비스에는 별도의 스키마(DTO)가 사용되는 변형입니다. 애플리케이션 계층은 관계형 데이터를 사전 정의된 스키마로 변환합니다. 이것의 가장 큰 장점은 서비스를 참조하는 모든 애플리케이션이 구성 요소의 내부 구현 유형에 의존하지 않는다는 것입니다. 이를 통해 버전 관리의 유연성, 인터페이스의 이전 버전과의 호환성, 서비스 인터페이스를 변경하지 않고도 구성 요소 구현을 변경할 수 있는 기능이 가능해졌습니다.

물론 웹 응용 프로그램에서 비즈니스 개체를 사용하고 DTO 변환을 우회할 수 있지만 이는 일반적으로 응용 프로그램 논리가 웹 응용 프로그램과 함께 구현되는 경우에만 잘 작동합니다. Order.Save()를 호출하려면 데이터베이스 연결. 이것이 바람직한지 여부는 귀하와 아마도 귀하의 보안 책임자에게 달려 있습니다.