다음을 통해 공유

2부 - 아키텍처

  • 아티클

플랫폼 간 앱을 빌드하는 핵심 개념은 플랫폼 간에 코드 공유를 최대화하는 데 사용할 수 있는 아키텍처를 만드는 것입니다. 다음 개체 지향 프로그래밍 원칙을 준수하면 잘 설계된 애플리케이션을 빌드하는 데 도움이 됩니다.

  • 캡슐화 – 클래스와 아키텍처 계층이 필요한 함수를 수행하고 구현 세부 정보를 숨기는 최소 API만 노출하도록 합니다. 클래스 수준에서 이는 개체가 '블랙박스'로 동작하며, 코드를 사용하는 경우 작업을 수행하는 방법을 알 필요가 없음을 의미합니다. 아키텍처 수준에서는 더 추상적인 계층의 코드를 대신하여 더 복잡한 상호 작용을 오케스트레이션하는 간소화된 API를 장려하는 외관과 같은 패턴을 구현하는 것을 의미합니다. 즉, UI 코드(예: 화면 표시 및 사용자 입력 허용)만 담당해야 합니다. 데이터베이스와 직접 상호 작용하지 않습니다. 마찬가지로 데이터 액세스 코드는 데이터베이스를 읽고 써야 하지만 단추 또는 레이블과 직접 상호 작용해서는 안 됩니다.
  • 책임 분리 – 각 구성 요소(아키텍처 및 클래스 수준 모두)에 명확하고 잘 정의된 용도가 있는지 확인합니다. 각 구성 요소는 정의된 작업만 수행하고 해당 기능을 사용해야 하는 다른 클래스에서 액세스할 수 있는 API를 통해 노출해야 합니다.
  • 다형성 – 여러 구현을 지원하는 인터페이스(또는 추상 클래스)로 프로그래밍한다는 것은 플랫폼별 기능과 상호 작용하면서 플랫폼 간에 핵심 코드를 작성하고 공유할 수 있음을 의미합니다.

자연스러운 결과는 실제 또는 개별 논리 계층이 있는 추상 엔터티를 모델로 한 애플리케이션입니다. 코드를 계층으로 분리하면 애플리케이션을 더 쉽게 이해하고 테스트하고 기본 수 있습니다. 각 계층의 코드는 논리적으로 분리(네임스페이스 사용)뿐만 아니라 디렉터리 또는 매우 큰 애플리케이션에 대한 별도의 프로젝트에서도 물리적으로 분리하는 것이 좋습니다.

일반적인 애플리케이션 계층

이 문서와 사례 연구 전체에서 다음 6개의 애플리케이션 계층을 참조합니다.

  • 데이터 계층 – 비휘발성 데이터 지속성( SQLite 데이터베이스일 가능성이 높지만 XML 파일 또는 기타 적합한 메커니즘으로 구현될 수 있음)
  • 데이터 액세스 계층 – 구현 세부 정보를 호출자에게 노출하지 않고 CRUD(만들기, 읽기, 업데이트, 삭제) 액세스를 제공하는 데이터 계층의 래퍼입니다. 예를 들어 DAL에는 데이터를 쿼리하거나 업데이트하는 SQL 문이 포함될 수 있지만 참조 코드는 이를 알 필요가 없습니다.
  • 비즈니스 계층 – (비즈니스 논리 계층 또는 BLL이라고도 함)에는 비즈니스 엔터티 정의(모델) 및 비즈니스 논리가 포함됩니다. 비즈니스용 외관 패턴입니다.
  • 서비스 액세스 계층 – 클라우드의 서비스에 액세스하는 데 사용됩니다. 복잡한 웹 서비스(REST, JSON, WCF)에서 원격 서버에서 데이터 및 이미지를 간단하게 검색합니다. 네트워킹 동작을 캡슐화하고 애플리케이션 및 UI 계층에서 사용할 간단한 API를 제공합니다.
  • 애플리케이션 계층 – 일반적으로 플랫폼별(일반적으로 플랫폼에서 공유되지 않음) 또는 애플리케이션과 관련된 코드(일반적으로 재사용할 수 없음)인 코드입니다. 애플리케이션 계층과 UI 계층에 코드를 배치할지 여부를 테스트하는 좋은 테스트는 (a) 클래스에 실제 디스플레이 컨트롤이 있는지 또는 (b) 여러 화면 또는 장치(예: i전화 및 iPad) 간에 공유할 수 있는지 여부를 확인하는 것입니다.
  • UI(사용자 인터페이스) 계층 – 사용자 연결 계층에는 화면, 위젯 및 이를 관리하는 컨트롤러가 포함됩니다.

애플리케이션이 모든 계층을 포함할 필요는 없습니다. 예를 들어 서비스 액세스 계층은 네트워크 리소스에 액세스하지 않는 애플리케이션에 존재하지 않습니다. 매우 간단한 애플리케이션은 작업이 매우 기본적이기 때문에 데이터 계층 및 데이터 액세스 계층을 병합할 수 있습니다.

일반적인 모바일 소프트웨어 패턴

패턴은 일반적인 문제에 대한 되풀이 솔루션을 캡처하는 확립된 방법입니다. 기본 지속 가능하고 이해할 수 있는 모바일 애플리케이션을 빌드하는 데 유용한 몇 가지 주요 패턴이 있습니다.

  • 모델, 뷰, ViewModel(MVVM) – Model-View-ViewModel 패턴은 Xamarin.Forms와 같은 데이터 바인딩을 지원하는 프레임워크에서 널리 사용됩니다. WPF(Windows Presentation Foundation) 및 Silverlight와 같은 XAML 지원 SDK에 의해 대중화되었습니다. 여기서 ViewModel은 데이터 바인딩 및 명령을 통해 데이터(모델)와 사용자 인터페이스(보기) 간의 이동 간 역할을 합니다.
  • MVC(모델, 뷰, 컨트롤러) – 일반적이고 종종 오해되는 패턴인 MVC는 사용자 인터페이스를 빌드할 때 가장 자주 사용되며, UI 화면의 실제 정의(보기), 상호 작용을 처리하는 엔진(컨트롤러) 및 이를 채우는 데이터(모델) 간의 구분을 제공합니다. 모델은 실제로 완전히 선택적이므로 이 패턴을 이해하는 핵심은 뷰 및 컨트롤러에 있습니다. MVC는 iOS 애플리케이션에 널리 사용되는 방법입니다.
  • 비즈니스 외관 – AKA 관리자 패턴은 복잡한 작업에 대한 간단한 진입점을 제공합니다. 예를 들어 작업 추적 애플리케이션에는 , 등과 같은 GetAllTasks()GetTask(taskID) 메서드가 있는 TaskManager 클래스가 SaveTask (task) 있을 수 있습니다. 클래스는 TaskManager 실제로 작업 개체를 저장/검색하는 내부 작업에 외관을 제공합니다.
  • 싱글톤 – 싱글톤 패턴은 특정 개체의 단일 인스턴스만 존재할 수 있는 방법을 제공합니다. 예를 들어 모바일 애플리케이션에서 SQLite를 사용하는 경우 데이터베이스 인스턴스가 하나만 필요합니다. 싱글톤 패턴을 사용하는 것은 이를 보장하는 간단한 방법입니다.
  • 공급자 – Silverlight, WPF 및 WinForms 애플리케이션에서 코드 재사용을 장려하기 위해 Microsoft에서 만든 패턴(전략 또는 기본 종속성 주입과 유사함). 공유 코드는 인터페이스 또는 추상 클래스에 대해 작성할 수 있으며, 코드가 사용될 때 플랫폼별 구체적인 구현이 작성되고 전달됩니다.
  • 비동기 – 비동기 키워드(keyword) 혼동하지 말고 UI 또는 현재 처리를 유지하지 않고 장기 실행 작업을 실행해야 하는 경우 비동기 패턴이 사용됩니다. 가장 간단한 형식에서 비동기 패턴은 장기 실행 작업이 다른 스레드(또는 작업과 같은 유사한 스레드 추상화)에서 시작되어야 하며, 현재 스레드는 백그라운드 프로세스에서 응답을 계속 처리하고 수신 대기한 다음 데이터 및 상태가 반환될 때 UI를 업데이트한다고 설명합니다.

각각의 패턴은 사례 연구에서 실제 사용이 설명되어 있으므로 더 자세히 검사됩니다. Wikipedia에는 MVVM, MVC, 외관, 싱글톤, 전략 및 공급자 패턴(및 일반적으로 디자인 패턴)에 대한 자세한 설명이 있습니다.