대규모 UI 애플리케이션의 미래 대비 - 2008 기능 팩이 포함된 MFC, 아니면 C# 및 Winforms?

https://stackoverflow.com/questions/10901

08-06-2019
|

문제

우리 회사는 Visual C++의 MFC를 UI 개발의 사실상 표준으로 사용하여 오랫동안 제품을 개발해 왔습니다.우리의 코드베이스에는 계속 작동해야 하는 레거시/구식 코드가 많이 포함되어 있습니다.이 코드 중 일부는 나보다 오래되었고(원래 70년대 후반에 작성됨) 우리 팀의 일부 구성원은 여전히 Visual Studio 6을 사용하고 있습니다.

하지만 다행스럽게도 우리 제품이 경쟁사 제품에 비해 다소 낡아 보인다는 점과 개선이 필요하다는 결론이 내부적으로 나왔습니다.

저는 현재 제품의 나머지 부분과는 상당히 다른 UI의 새로운 영역을 작업하고 있습니다.따라서 나머지 UI로 이동하는 긴 프로세스가 시작되기 전에 일종의 시험장으로 '새로운' 기술 스택을 시험해 볼 기회가 주어졌습니다.

한동안 여가시간에 Windows Forms와 .net 프레임워크와 함께 C#을 사용하며 즐기고 있지만, 상호 운용성으로 인한 골칫거리가 다소 걱정됩니다.이 특정 UI 분기에는 레거시 C++ 코드베이스와의 상호 운용성이 많이 필요하지 않지만 앞으로 이것이 문제가 될 것으로 예상됩니다.

대안은 MFC를 계속 사용하는 것이지만 VS2008과 함께 제공되는 새로운 기능 팩을 활용해 보십시오.이것이 가장 쉬운 옵션인 것 같지만, 수명이 걱정되고 .net의 장점을 활용하지 못할까 걱정됩니다...

그렇다면 나는 어느 것을 선택해야 할까요?우리는 소규모 팀이기 때문에 제가 제안하는 것이 우리 개발의 미래 방향으로 받아들여질 가능성이 높습니다. 저는 그것을 올바르게 하고 싶습니다.

MFC는 죽었나요?C#/Winforms가 앞으로 나아갈 길인가요?내가 완전히 놓친 다른 것이 있습니까?도움을 주셔서 대단히 감사합니다!

해결책

저는 수많은 레거시 MFC 코드가 포함된 앱의 개발자이며 여러분 모두와 동일한 우려 사항을 갖고 있습니다.우리 전략의 가장 큰 원동력은 위험과 불확실성을 최대한 제거하는 것이었고, 이는 The Big Rewrite를 피하는 것을 의미했습니다.우리 모두 알고 있듯이 TBR은 대부분 실패합니다.그래서 우리는 현재 릴리스에서 변경되지 않는 모듈을 보존하고, 새로운 관리 기능을 작성하고, 개선되는 기능을 관리 기능으로 이식할 수 있는 점진적인 접근 방식을 선택했습니다.

이 작업은 여러 가지 방법으로 수행할 수 있습니다.

MFC 뷰에서 WPF 콘텐츠를 호스팅합니다(참조: 여기)
MFC MDI 앱의 경우 새 WinForms 프레임워크를 만들고 MFC MDI 보기를 호스팅합니다(참조). 여기)
MFC 대화 상자 및 보기에서 WinForms 사용자 컨트롤을 호스팅합니다(참조: 여기)

WPF(옵션 1)를 채택할 때의 문제점은 모든 UI를 한 번에 다시 작성해야 한다는 것입니다. 그렇지 않으면 꽤 정신분열적으로 보일 것입니다.

두 번째 접근 방식은 실행 가능해 보이지만 매우 복잡합니다.

세 번째 접근 방식은 우리가 선택한 접근 방식으로 매우 잘 작동하고 있습니다.이를 통해 전반적인 일관성을 유지하고 깨지지 않은 부분을 건드리지 않으면서 앱의 영역을 선택적으로 새로 고칠 수 있습니다.

Visual C++ 2008 기능 팩은 흥미로워 보이지만 아직 사용해 본 적은 없습니다.오래된 모양 문제를 해결하는 데 도움이 될 것 같습니다."리본"이 사용자에게 너무 거슬리는 경우 타사 MFC 및/또는 WinForms 컨트롤 공급업체를 살펴볼 수 있습니다.

제가 전반적으로 권장하는 사항은 전면적인 변경보다 interop + 증분 변경이 확실히 바람직하다는 것입니다.

귀하의 후속 조치를 읽은 후에는 프레임워크를 배우는 데 투자하는 것보다 프레임워크의 생산성 향상이 훨씬 더 크다는 것을 확실히 확인할 수 있습니다.이 작업을 시작할 때 우리 팀의 어느 누구도 C#을 사용하지 않았으나 지금은 모두 C#을 선호합니다.

다른 팁

응용 프로그램과 .NET을 설치하려는 고객의 의지(일부 모두는 아님)에 따라 저는 확실히 WinForms 또는 WPF로 이동할 것입니다.C++/CLI를 사용하여 UI가 아닌 코드를 클래스 라이브러리로 리팩터링하면 C++ 코드와의 상호 운용성이 크게 단순화됩니다(태그 선택에서 언급한 대로).

WPF의 유일한 문제는 현재의 모양과 느낌을 유지하기 어려울 수 있다는 것입니다.GUI의 현재 모양을 유지하면서 WinForms로 이동할 수 있습니다.WPF는 현재 레이아웃을 유지하려고 시도하는 것이 아마도 쓸데없는 일이고 확실히 WPF의 정신에 맞지 않는 다른 모델을 사용합니다.또한 WPF는 둘 이상의 WPF 프로세스가 실행 중인 경우 Vista 이전 컴퓨터에서 성능이 떨어지는 것으로 보입니다.

내 제안은 고객이 무엇을 사용하고 있는지 알아내는 것입니다.대부분이 Vista로 전환했고 팀이 많은 GUI 작업을 수행할 준비가 되어 있다면 WinForms를 건너뛰고 WPF로 전환할 것입니다.그렇지 않으면 확실히 WinForms를 진지하게 살펴보십시오.두 경우 모두 C++/CLI의 클래스 라이브러리가 상호 운용성 문제에 대한 답입니다.

레거시 코드의 기능이나 구조에 대해 자세히 설명하지 않습니다.특정 성능 기준이 있는 경우 일부 코드베이스를 C++로 유지하고 싶을 수도 있습니다.올바른 방식으로 노출되면 이전 코드와의 상호 운용성을 더 쉽게 수행할 수 있습니다. 지금 C#에서 기존 코드베이스를 호출할 수 있습니까?이 구조를 올바르게 만들기 위한 프로젝트에 대해 생각해 볼 가치가 있습니다.

WPF의 관점에서는 WinForms가 더 적합할 수 있다고 주장할 수 있습니다.WinForms로 전환하는 것은 귀하와 귀하의 팀에게 큰 진전입니다.아마도 그들은 WinForms로 전환하는 것이 더 편할 수도 있습니다.더 잘 문서화되어 있고 시장에서의 더 많은 경험이 있으며 여전히 Windows 2000 클라이언트를 지원해야 하는 경우 유용합니다.

당신은 관심이있을 수 있습니다 .NET Framework를 사용하여 MFC 애플리케이션 확장

고려해야 할 또 다른 점은 C++/CLI, 그러나 나는 그것에 대한 경험이 없습니다.

귀하의 답변에 친절하게 감사드립니다. 일반적으로 합의가 내 사고 방식을 따른다는 것을 확인하면 안심이 됩니다.다행스럽게도 우리 소프트웨어도 우리 고유의 맞춤형 하드웨어(방송 업계용)에서 실행됩니다. 따라서 OS 선택은 실제로 우리의 몫이며 고객이 선택해야 합니다.현재 우리는 XP/2000을 실행하고 있지만 곧 Vista로 전환하고 싶은 마음이 들었습니다.

하지만 GPU 성능에 대한 매우 세밀한 제어도 유지해야 합니다. 그러면 WPF와 하드웨어 가속이 자동으로 배제됩니다.원래 게시물에서 그 점을 언급했어야 했는데 죄송합니다.아마도 두 개의 GPU를 사용하는 것이 가능할 것입니다 ...하지만 그것은 전혀 다른 질문입니다 ...

팀은 C#에 대한 중요한 경험이 없고 나도 전문가는 아니지만 관리되는 환경의 전반적인 장기적 이점이 속도를 높이는 데 걸리는 시간보다 더 클 것이라고 생각합니다.

현재로서는 Winforms와 C#이 이를 갖고 있는 것 같습니다.

C#으로 전환하여 .NET으로 전환할 계획이라면 WinForms보다는 Windows Presentation Foundation을 고려하겠습니다.WPF는 .NET 스마트 클라이언트의 미래이며, 브라우저에서 호스팅되는 Silverlight 응용 프로그램을 만들려는 경우 습득한 기술을 재사용할 수 있습니다.

나는 WPF 정서에 동의합니다.태그/XML 기반 UI는 WinForms보다 이식성이 더 좋은 것 같습니다.

나는 또한 당신의 팀을 고려해야 한다고 생각합니다. 현재 C# 기술이 많지 않다면 그것이 하나의 요인이 될 것입니다. 그러나 앞으로 MFC 개발자 시장은 줄어들고 C#은 성장하고 있습니다.

어쩌면 일종의 단편적인 접근 방식이 가능할 수도 있을까요?저는 레거시 애플리케이션을 C#으로 다시 코딩하는 일에 꽤 많이 참여해 왔으며, 특히 일부 레거시 코드를 유지하고 있거나 팀이 C#에 능숙하지 않은 경우 예상보다 항상 훨씬 더 오랜 시간이 걸립니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow