Windows 8 용 엔터프라이즈 데스크톱 응용 프로그램을 설계하는 방법

Windows 8의 소비자 응용 프로그램 개발에 대한 기대를 파악하고 있다고 생각합니다. WinRT 위에 새로운 Metro 기반 UI를 만들고 Marketplace를 통해 고객에게 배포하면 모두가 승리합니다. 충분히 간단 해 보입니다. 불행히도, 나는 그 사업에 있지 않습니다.

대기업을위한 내부 업무용 응용 프로그램을 작업하고 있습니다. 현재 웹이나 ClickOnce를 통해 사용자에게 쉽게 배포 할 수있는 풍부한 UI를 만들기 위해 WPF 및 Silverlight와 같은 .NET 기술을 사용합니다. 이 응용 프로그램은 너무 많은 두통없이 WinXP 및 Win7을 지원할 수 있으며 개발자는 매우 견고한 UI 기술인 XAML을 사용하게됩니다.

현재 WPF와 Silverlight는 의심스러운 미래를 가지고있는 것처럼 보이므로 계속 투자하는 것이 조금 걱정입니다. 그러나 Metro UI는 엔터프라이즈 응용 프로그램에 적합하지 않은 것으로 보이며 WinRT API는 엔터프라이즈 응용 프로그램이 수행해야하는 "일반적인"작업과 관련하여 상당히 제한적입니다.

WinXP 및 Win7에 현재 배포되고있는 XAML 기반 응용 프로그램을 Win8에서 지원 및 진화 할 수 있도록 어떻게 설계해야합니까?

이 질문의 목적 상 ASP.NET 위에 HTML5가 제공하는 기능이 내가 만들려는 응용 프로그램에 적합하지 않다고 가정하십시오. 일부 응용 프로그램에 HTML5를 사용할 수 있다는 것을 알고 있지만 충분하지 않은 경우 어떻게해야하는지 파악하려고합니다.

편집 # 1 : @Emmad Kareem의 의견에 대한 답변입니다. Silverlight / WPF가 단기간 (2-5 년)에 실행 가능하다는 데 동의합니다. 그러나 우리가 생산하는 애플리케이션은 수명이 매우 길다 (10-20 년 이상). 따라서 주어진 기술에 대한 장기 생존 가능성은 우리의 관심사입니다. 또한 Silverlight / WPF 개발에 관심이있는 개발자를 커뮤니티에서 "죽은"것으로 간주하면 개발자를 찾는 것이 점점 더 어려워 질 것이라는 우려가 있습니다. 옵션을 이해하고 눈을 뜨고 결정을 내리고 싶습니다.

MS-Stack 걱정을 멈추고 사랑하는 법을 배우는 방법

Windows 8 에서도 VB6 앱을 계속 실행할 수 있습니다 . MS 에코 시스템에서는 선과 악의 역 호환성 이 항상 트렌드였습니다. WPF / Silveright와 같은 기술의 생존과 그 문제에 대한 winforms에 대해 걱정할 필요가 없습니다.

반면에 장기 프로젝트의 경우 최신 기술을 사용하지 않아야합니다.

실제로 기술 선택에 대해 스스로에게 물어봐야 할 질문은 다음과 같습니다.

• 우리 팀은 그 기술을 충분히 사용하여 생산성을 높일 수 있습니까?
• 우리 팀은 그 기술을 기꺼이 사용합니까?
• 그 기술에 대한 사람들을 모집 할 수 있습니까?

그것은 마케팅상의 이유로 주로 만들어지는 트렌드가 아니라 선택을 이끌어야하는이 질문에 대한 답변의 조합입니다.

끊임없이 변화하는 기술의 주제에 대한 자세한 내용은 Joel Spolsky의 "Fire And Motion" 을 읽어보십시오 .

걸려 넘어지는 회사는 차잎을 읽는 데 너무 많은 시간을 소비하여 Microsoft의 미래 방향을 파악하는 회사입니다. 사람들은 .NET에 대해 걱정하고 .NET에 대한 전체 아키텍처를 다시 작성하기로 결정했습니다. 마이크로 소프트는 당신을 쏘고있다. 그리고 그것은 단지 화재를 막아서 그들이 앞으로 나아갈 수 있고 당신이 할 수없는 것이다. 우박을 지원할 예정입니까? 비누? RDF? 고객이 필요로하거나 누군가가 당신을 향해 쏘아서 응답해야한다고 느끼기 때문에 지원하고 있습니까? 대기업의 영업 팀은 커버 화재를 이해합니다.

그리고 그것은 거의 10 년 전에 쓰여졌습니다.

건축과 기술

아키텍처와 기술은 다음 두 가지 작업과 선택입니다.

• winforms로 MVC를 수행 할 수 있습니다 .
• WPF / Silverlight로 MVVM을 수행 할 수 있습니다 .
• ASP.NET으로 MVC를 수행 할 수 있습니다 .
• WINRT를 사용하면 MVC 및 MVVM을 포함하여 원하는 모든 작업을 수행 할 수 있습니다 .
• F # 으로 기능을 수행 할 수 있습니다 . 왜 안돼? 의미가있는 도메인이 있습니다.
• 그것들을 모두 혼합하고 공통 시스템에 대한 다른 진입 점을 갖은 다음 너무 복잡해지기 때문에 조롱 할 수 있습니다 .

서비스, ​​리소스, 타사 컨트롤, ORM 등을이 모든 기술과 함께 사용하거나 다음 기술과 함께 사용하거나 사용하지 않을 수 있습니다.

이러한 모든 기술을 사용하여 여러 가지 방법으로 MVC를 비틀거나 구부릴 수 있습니다. 코드가 보이지 않거나 보이지 않습니까? 컨트롤러 또는 아닙니다? 매번 또는 필요할 때만 ViewModel? 하나의 특정 기술 범위 내에서도 디자인 패턴을 구현하는 방법에는 여러 가지가 있습니다.

그것은 당신의 프로젝트와 팀에 대한 사전 지식없이 그들 중 하나에 당신을 강요하는 것은 비현실적입니다. 그것은 개인적인 취향에 기초 할 뿐이며, "나의 기술은 당신보다 낫다"대결에서 끝날 것이다.

정직하고 객관적으로 제안 할 수있는 유일한 것은 적용 할 수있는 모범 사례를 사용하여 시간의 테스트를 견딜 수있는 아키텍처를 만드는 것입니다. . 또한 업그레이드 가능성 / 이동성이 아키텍처의 주요 목적이되어서는 안됩니다.

아키텍처 및 선택한 기술의 주요 목적은 실제 요구 사항을 충족하는 상사 / 고객에게 제품을 제공하는 것입니다.

MVC (그리고 남동생 MVVM)는 1979 년 이후 OOP 언어 분야와 그 이후의 견고한 아키텍처의 기반으로 점점 더 많이 입증되었습니다 . 그러나 10 년 동안의 프로젝트에서 어떤 기술을 사용해야할지 선택하는 것은 당신의 결정으로 남아 있습니다.

MVVM에 대한 저의 책에서 다룰 한 가지는 재사용 가능한 핵심 응용 프로그램을 만들기 위해 패턴을 활용하는 방법입니다. 대상으로하는 다양한 플랫폼 (웹, silverlight, 전화, WPF 또는 WinRT 등)에 대한 기본 UI를 작성해야합니다. 그러나 대부분 UI를 ViewModel 뒤에 배치하는 논리를 캡슐화 할 수 있습니다.

액세스하는 모든 서비스는 플랫폼간에 이식성이 뛰어난 인터페이스 (Facade 패턴)로 둘러싸여 야합니다. 인터페이스는 전면의 클라이언트 API에 매핑되고 후면의 래핑 된 서비스의 API로 변환되어야합니다.

이 전략을 사용하면 새로운 UI 만 계층화 할 수있는 견고한 핵심 프레임 워크를 만들 수 있습니다. 그것을 뷰 모델이 근육 인 것으로 생각하면 서비스는 골격 (및 장기)을 만듭니다. WPF / Silverlight / WinRT는 피부를 형성합니다.

사실, 필자의 책에서 매우 일찍 지적한 것은 MVVM이 새로운 것처럼 보이지 않는다는 것입니다. Dolphin Smalltalk는 MMVC (두 M은 응용 프로그램 모델 및 도메인 모델)와 비슷한 패턴을 가졌습니다. 오늘날 우리가 사용하는 ViewModel은 MMVC의 애플리케이션 모델과 컨트롤러의 조합 일뿐입니다. 실제로 많은 개발자들은 때때로 ViewModel을 두 가지 구성 요소로 분리하는 것이 합리적이라는 것을 알게되었습니다 (컨트롤러는 여러 VM을 탐색하고 오케스트레이션하는 데 사용되어 VM이 다른 구성 요소를 행복하게 알지 못하도록 유지할 수 있음).

XAML은 견고하지만 WPF는 미래가 의심 스럽다고 말합니다. 내가 빠진 것이 아니라면 WPF는 XAML을 사용하며 둘이 분리되는 것을 보지 못합니다. WPF에 대해 다른 기본 기술을 사용하거나 Microsoft가 UI를 빌드 하는 또 다른 새로운 방법을 고려할 가능성에 대해 놓친 소식이 있습니까? 그 외에도 WPF가 어디로 가고 있는지 의심 스럽지만 MS가 코드의 보트로드를 폐기 한 것은 이번이 처음이 아닙니다 ...

풍부한 UI 응용 프로그램이 필요하고 HTML5가 자르지 않고 Windows OS에 전념하고 있다면 WPF가 winforms에 대해 가장 마지막 / 가장 큰 것이므로 최선의 선택이라고 생각합니다 ...

이것에 대한 나의 취지는 응용 프로그램의 구현 세부 사항에 너무 집중해서는 안된다는 것입니다. 더 큰 그림을 보면 기술 종속성을 격리 할 수 ​​있습니다. 예를 들어 xaml / wpf / silverlight에 대한 의존성을 통해 ui 구성 요소 / 기술을 차세대 기술로 대체 할 수 있으므로 20 년 내에도 연속성을 보장 할 수 있습니다. 또한 시스템 구성 요소를 분리하고 그러한 교체를 수행해야하는 영향에 도움이됩니다. (이에 서 나는 연속성을 제공하기 위해 차세대 플랫폼에서 사용할 수있는 솔루션을 고민하는 것이 좋다고 가정합니다)

이러한 기술 종속성으로부터 격리를 제공하는 다른 방법은 가상화를 활성화하는 것입니다. vm에서 실행할 수있는 방식으로 응용 프로그램을 만들면 20 년 안에 그렇게 할 수 있습니다!