Tương lai kiểm chứng một ứng dụng giao diện người dùng lớn - MFC với gói tính năng 2008, hoặc C# và Winforms?

Question

Công ty của tôi đã phát triển một sản phẩm lâu dài sử dụng MFC trong Visual C++ làm tiêu chuẩn defacto cho phát triển UI. Codebase của chúng tôi chứa ALOT của mã cũ/cổ mà phải được duy trì hoạt động. Một số mã này cũ hơn tôi (ban đầu được viết vào cuối những năm 70) và một số thành viên trong nhóm của chúng tôi vẫn còn trên Visual Studio 6.

Tuy nhiên, kết luận đã may mắn đạt được rằng sản phẩm của chúng tôi có vẻ hơi lỗi thời cho các đối thủ cạnh tranh của chúng tôi 'và điều gì đó cần phải được thực hiện.

Tôi hiện đang làm việc trên một khu vực mới của giao diện người dùng hoàn toàn tách biệt với phần còn lại của sản phẩm. Do đó, tôi đã có cơ hội thử các ngăn xếp công nghệ 'mới' như một loại chứng minh nền tảng trước khi quá trình di chuyển dài trong phần còn lại của giao diện người dùng bắt đầu.

Tôi đã sử dụng C# với Windows Forms và khung .net trong một thời gian rảnh và tận hưởng nó, nhưng có phần lo lắng về những cơn đau đầu do interop gây ra. Trong khi nhánh đặc biệt này của giao diện người dùng sẽ không yêu cầu nhiều interop với codebase C++ kế thừa, tôi có thể coi đây là vấn đề trong tương lai.

Cách khác là tiếp tục với MFC, nhưng hãy thử và tận dụng lợi thế của gói tính năng mới đi kèm với VS2008. Điều này tôi đoán là lựa chọn đơn giản nhất, nhưng tôi lo lắng về tuổi thọ và không tận dụng lợi thế của sự tốt đẹp đó là ...

Vì vậy, tôi nên chọn cái nào? Chúng tôi là một nhóm nhỏ nên đề xuất của tôi có lẽ sẽ được chấp nhận như một hướng tương lai cho sự phát triển của chúng tôi - tôi muốn làm đúng.

MFC có bị chết không? Là C#/Winforms con đường phía trước? Có điều gì khác tôi hoàn toàn mất tích? Giúp đánh giá cao!

Answer 1

Tôi là nhà phát triển trên ứng dụng có rất nhiều mã MFC cũ và chúng tôi có tất cả các mối quan tâm tương tự của bạn. Một động lực lớn cho chiến lược của chúng tôi là loại bỏ càng nhiều rủi ro và không chắc chắn nhất có thể, điều đó có nghĩa là tránh được The Big Rewrite. Như chúng ta đều biết, TBR thất bại phần lớn thời gian. Vì vậy, chúng tôi đã chọn một phương pháp gia tăng cho phép chúng tôi duy trì các mô-đun sẽ không thay đổi trong bản phát hành hiện tại, viết các tính năng mới được quản lý và các tính năng đang được cải tiến để quản lý.

Bạn có thể làm nhiều cách khác nhau này:

1. Máy chủ nội dung WPF trên quan điểm MFC của bạn (xem here)

2. Đối với các ứng dụng MFC MDI, tạo ra một khuôn khổ WinForms mới và tổ chức quan MFC MDI của bạn (xem here)

3. điều khiển WinForms Máy chủ dùng trong MFC Dialogs và xem (xem here)

Vấn đề với việc áp dụng WPF (tùy chọn 1) là nó sẽ yêu cầu bạn viết lại tất cả giao diện người dùng cùng một lúc, nếu không nó sẽ trông khá phân liệt.

Cách tiếp cận thứ hai có vẻ khả thi nhưng rất phức tạp.

Cách tiếp cận thứ ba là phương pháp chúng tôi đã chọn và phương pháp này hoạt động rất tốt. Nó cho phép bạn làm mới có chọn lọc các khu vực của ứng dụng của bạn trong khi duy trì tính nhất quán tổng thể và không chạm vào những thứ không bị hỏng.

Gói tính năng Visual C++ 2008 trông thú vị, tôi chưa từng chơi với nó. Có vẻ như nó có thể giúp bạn giải quyết vấn đề lỗi thời. Nếu "ribbon" sẽ quá chói tai đối với người dùng của bạn, bạn có thể xem các nhà cung cấp kiểm soát MFC và/hoặc WinForms của bên thứ ba.

Đề xuất tổng thể của tôi là thay đổi liên tục + gia tăng chắc chắn là thích hợp hơn để quét các thay đổi.

---

Sau khi đọc tiếp theo, tôi chắc chắn có thể xác nhận rằng lợi ích về năng suất của khung lớn hơn nhiều so với đầu tư trong việc học nó. Không ai trong nhóm của chúng tôi đã sử dụng C# khi bắt đầu nỗ lực này và bây giờ tất cả chúng tôi đều thích nó.

Answer 2

Bạn có muốn xem xét chuyển sang C# và do đó .NET không, tôi sẽ xem xét Windows Presentation Foundation hơn là WinForms. WPF là tương lai của các khách hàng thông minh trong .NET và các kỹ năng bạn chọn sẽ có thể sử dụng lại nếu bạn muốn tạo các ứng dụng Silverlight được lưu trữ trên trình duyệt.

Answer 3

Tôi đồng ý với ý kiến ​​WPF. Giao diện người dùng dựa trên thẻ/XML có vẻ di động hơn một chút so với WinForms.

Tôi đoán bạn cũng phải xem xét nhóm của mình, nếu không có nhiều kỹ năng C# hiện tại, thì đó là một yếu tố, nhưng sẽ tiếp tục thị trường cho các nhà phát triển MFC đang giảm dần và C# đang phát triển.

Có thể một số phương pháp tiếp cận từng phần sẽ có thể thực hiện được? Tôi đã được tham gia với recoding ứng dụng di sản để C# khá một chút, và nó luôn luôn mất nhiều thời gian hơn bạn sẽ ước tính, đặc biệt là nếu bạn đang giữ một số mã di sản, hoặc nhóm của bạn không phải là đối thoại với C#.

Answer 4

Tùy thuộc vào ứng dụng và sự sẵn sàng của khách hàng của bạn để cài đặt .NET (không phải tất cả trong số đó), tôi chắc chắn sẽ chuyển sang WinForms hoặc WPF. Interop với mã C++ được đơn giản hóa rất nhiều bằng cách tái cấu trúc mã không phải UI thành các thư viện lớp bằng cách sử dụng C++/CLI (như bạn đã lưu ý trong lựa chọn các thẻ của bạn).

Vấn đề duy nhất với WPF là có thể khó duy trì giao diện hiện tại. Di chuyển đến WinForms có thể được thực hiện trong khi vẫn duy trì giao diện hiện tại của GUI của bạn. WPF sử dụng một mô hình khác nhau để cố gắng giữ cho bố cục hiện tại có thể là vô ích và chắc chắn sẽ không ở trong tinh thần của WPF. WPF cũng có hiệu suất kém trên các máy trước Vista khi có nhiều hơn một tiến trình WPF đang chạy.

Đề xuất của tôi là tìm hiểu những gì khách hàng của bạn đang sử dụng.Nếu hầu hết đã chuyển sang Vista và nhóm của bạn đã sẵn sàng để đưa vào rất nhiều công việc GUI, tôi sẽ nói bỏ qua WinForms và chuyển sang WPF. Nếu không, chắc chắn nhìn nghiêm túc tại WinForms. Trong cả hai trường hợp, một thư viện lớp trong C++/CLI là câu trả lời cho các mối quan tâm interop của bạn.

Answer 5

Bạn không cung cấp nhiều thông tin chi tiết về mã di sản của bạn hoặc cách mã được cấu trúc. Nếu bạn có một số tiêu chí hiệu suất nhất định, bạn có thể muốn duy trì một số codebase của mình trong C++. Bạn sẽ có một thời gian dễ dàng hơn để làm interop với mã cũ của bạn nếu nó được tiếp xúc đúng cách - bạn có thể gọi vào codebase hiện tại từ C# ngày hôm nay không? Có thể đáng suy nghĩ về một dự án để có được cấu trúc này đúng.

Về điểm của WPF, bạn có thể cho rằng WinForms có thể phù hợp hơn. Chuyển sang WinForms là một bước tiến lớn cho bạn và nhóm của bạn. Có lẽ họ có thể thoải mái hơn khi di chuyển đến WinForms? Đó là tài liệu tốt hơn, nhiều kinh nghiệm trên thị trường, và hữu ích nếu bạn vẫn cần phải hỗ trợ windows 2000 khách hàng.

Bạn có thể quan tâm Extending MFC Applications with the .NET Framework

Cái gì khác để xem xét là C++/CLI, nhưng tôi không có kinh nghiệm với nó.

Answer 6

Cảm ơn tất cả các bạn đã hài lòng vì câu trả lời của bạn, thật yên tâm khi thấy rằng sự đồng thuận chung theo dòng suy nghĩ của tôi. Tôi đang trong tình huống may mắn rằng phần mềm của chúng tôi cũng chạy trên phần cứng tùy chỉnh của chúng tôi (cho ngành công nghiệp phát sóng) - vì vậy sự lựa chọn của hệ điều hành thực sự là của chúng tôi và là lực đẩy khi khách hàng của chúng tôi. Hiện tại chúng tôi đang chạy XP/2000, nhưng tôi có thể thấy mong muốn sớm chuyển sang Vista.

Tuy nhiên, chúng tôi cũng cần phải duy trì kiểm soát rất tốt đối với hiệu suất GPU, điều mà tôi đoán tự động loại trừ khả năng tăng tốc phần cứng và WPF? Tôi nên đã làm cho điểm đó trong bài viết ban đầu của tôi - xin lỗi. Có lẽ có thể sử dụng hai GPU ... nhưng đó là một câu hỏi khác ...

Nhóm không có bất kỳ trải nghiệm C# đáng kể nào và tôi không phải là chuyên gia, nhưng tôi nghĩ rằng lợi ích lâu dài tổng thể của môi trường được quản lý có thể lớn hơn thời gian cần thiết để tăng tốc.

Dường như Winforms và C# có nó ngay bây giờ.