Cách kiến ​​trúc ứng dụng doanh nghiệp cho máy tính để bàn cho Windows 8

Tôi nghĩ rằng tôi đã nắm bắt được những kỳ vọng về phát triển ứng dụng tiêu dùng cho Windows 8. Tạo giao diện người dùng dựa trên Metro mới trên WinRT, triển khai nó cho khách hàng của bạn thông qua Marketplace và mọi người đều thắng. Có vẻ đủ đơn giản. Thật không may, tôi không kinh doanh.

Tôi làm việc trên các ứng dụng nội bộ, kinh doanh cho một doanh nghiệp lớn. Chúng tôi hiện đang sử dụng các công nghệ .NET như WPF và Silverlight để tạo UI phong phú có thể dễ dàng triển khai cho người dùng của chúng tôi thông qua web hoặc ClickOnce. Các ứng dụng có thể hỗ trợ WinXP và Win7 mà không phải quá đau đầu và các nhà phát triển của chúng tôi đã sử dụng XAML, một công nghệ UI rất vững chắc.

Có vẻ như WPF và Silverlight có tương lai đáng ngờ vào thời điểm này, vì vậy thật đáng lo ngại khi tiếp tục đầu tư vào những thứ đó. Nhưng một giao diện người dùng Metro dường như không phù hợp với các ứng dụng doanh nghiệp và API WinRT khá hạn chế đối với những điều "điển hình" mà các ứng dụng doanh nghiệp cần phải làm.

Tôi nên kiến ​​trúc các ứng dụng dựa trên XAML của mình như thế nào, hiện đang được triển khai lên WinXP và Win7, để chúng có thể hỗ trợ và có thể phát triển trên Win8?

Giả sử cho các mục đích của câu hỏi này rằng các tính năng được cung cấp bởi HTML5 trên ASP.NET không phù hợp với các ứng dụng tôi đang tìm cách tạo. Tôi hiểu rằng tôi có thể sử dụng HTML5 cho một số ứng dụng, nhưng tôi đang cố gắng tìm ra những gì tôi nên làm khi điều đó là không đủ.

Chỉnh sửa # 1: Đây là để phản ứng lại bình luận @Emmad Kareem của. Tôi đồng ý rằng Silverlight / WPF khả thi trong thời gian ngắn (2-5 năm). Tuy nhiên, các ứng dụng chúng tôi sản xuất có tuổi thọ rất dài (10-20 + năm). Vì vậy, khả năng sống sót trong dài hạn cho một công nghệ nhất định là mối quan tâm đối với chúng tôi. Ngoài ra, chúng tôi có một số lo ngại rằng việc tìm kiếm các nhà phát triển quan tâm đến phát triển Silverlight / WPF sẽ ngày càng khó khăn hơn nếu cộng đồng đó bị cộng đồng coi là "chết". Tôi chỉ muốn hiểu các lựa chọn của mình và đưa ra quyết định với đôi mắt mở.

Tôi đã học cách ngừng lo lắng và yêu thích MS-Stack như thế nào

Bạn vẫn có thể chạy các ứng dụng VB6 trên windows 8 . Khả năng tương thích retro tốt hay xấu luôn là xu hướng trong hệ sinh thái MS. Bạn không nên lo lắng về sự tồn tại của các công nghệ như WPF / Silveright, và thậm chí là winforms cho vấn đề đó.

Mặt khác, bạn phải chấp nhận rằng đối với một dự án dài hạn, bạn sẽ không bao giờ có công nghệ mới nhất, dễ thương nhất.

Trong thực tế, những câu hỏi bạn nên tự hỏi về sự lựa chọn công nghệ là:

• Đội của tôi có đủ thoải mái với công nghệ đó để làm việc hiệu quả không?
• Đội của tôi có vui khi sử dụng công nghệ đó không?
• Tôi có thể tuyển người cho công nghệ đó không?

Đó là sự kết hợp của các câu trả lời cho câu hỏi này sẽ dẫn đến sự lựa chọn của bạn, và không phải là xu hướng giả mạo chủ yếu vì lý do tiếp thị.

Để biết thêm về chủ đề công nghệ luôn thay đổi này, bạn nên đọc "Fire And Motion" của Joel Spolsky :

Các công ty vấp ngã là những người dành quá nhiều thời gian để đọc lá trà để tìm ra hướng đi trong tương lai của Microsoft. Mọi người lo lắng về .NET và quyết định viết lại toàn bộ kiến ​​trúc của họ cho .NET vì họ nghĩ rằng họ phải làm vậy. Microsoft đang bắn vào bạn, và nó chỉ bao trùm lửa để họ có thể tiến về phía trước và bạn không thể, bởi vì đây là cách trò chơi được chơi, Bubby. Bạn sẽ hỗ trợ Hailstorm? XÀ BÔNG TẮM? RDF? Bạn đang ủng hộ nó bởi vì khách hàng của bạn cần nó, hoặc bởi vì ai đó đang bắn vào bạn và bạn cảm thấy như bạn phải đáp ứng? Các đội bán hàng của các công ty lớn hiểu lửa bao trùm.

Và điều đó đã được viết gần mười năm trước.

Kiến trúc và Công nghệ

Kiến trúc và Công nghệ là hai điều riêng biệt và lựa chọn để làm:

• Bạn có thể làm MVC với winforms .
• Bạn có thể làm MVVM với WPF / Silverlight .
• Bạn có thể làm MVC với ASP.NET .
• Bạn có thể làm bất cứ điều gì bạn muốn, bao gồm cả MVC và MVVM, với WINRT theo như chúng tôi biết .
• Bạn có thể thực hiện chức năng với F # . Tại sao không ? Có những lĩnh vực mà nó sẽ có ý nghĩa.
• Bạn có thể kết hợp tất cả chúng, để có các điểm vào khác nhau cho một hệ thống chung, sau đó bị chế giễu vì quá phức tạp , v.v.

Bạn có thể sử dụng các dịch vụ, tài nguyên, điều khiển của bên thứ ba, ORM, v.v. với tất cả các công nghệ này, và có thể, hoặc có thể không, với các công nghệ tiếp theo.

Bạn có thể xoắn và uốn cong MVC theo nhiều cách với tất cả các công nghệ đó: Liên kết hay không? Mã phía sau xem hay không? Người điều khiển hay không? ViewModel mọi lúc hay chỉ khi cần? Có rất nhiều cách để thực hiện một mẫu thiết kế, thậm chí trong phạm vi của một công nghệ cụ thể.

Điều đó sẽ không thực tế khi buộc bạn vào một trong số họ mà không có kiến ​​thức nâng cao về dự án và nhóm của bạn. Nó sẽ chỉ dựa trên sở thích cá nhân, và cuối cùng trong một cuộc đấu "công nghệ của tôi tốt hơn của bạn".

Điều duy nhất có thể được đề xuất một cách trung thực và khách quan là sử dụng các thực tiễn tốt nhất bạn có thể áp dụng để tạo ra một kiến ​​trúc sẽ vượt qua thử thách của thời gian, và có thể, thực sự có thể sẽ được di động hoặc tái sử dụng ít nhất là trong các phần với công nghệ chưa biết trong tương lai . Và khả năng nâng cấp / tính di động đó thậm chí không phải là mục đích chính của kiến ​​trúc của bạn.

Mục đích chính của kiến ​​trúc và công nghệ được lựa chọn của bạn là cung cấp một sản phẩm cho sếp / khách hàng của bạn đáp ứng yêu cầu thực tế của anh ấy.

MVC (và đó là em trai MVVM) ngày càng chứng tỏ là cơ sở cho kiến ​​trúc mạnh mẽ kể từ năm 1979 trong lĩnh vực ngôn ngữ OOP và hơn thế nữa. Nhưng lựa chọn công nghệ cụ thể nào sẽ được sử dụng trong dự án dài 10 năm vẫn là quyết định của bạn.

Một điều tôi sẽ giải quyết trong cuốn sách của mình về MVVM là cách tận dụng mô hình để tạo ra một ứng dụng lõi có thể sử dụng lại. Bạn nên tạo một giao diện người dùng riêng cho các nền tảng khác nhau mà bạn nhắm mục tiêu (có thể là web, silverlight, phone, WPF hoặc WinRT). Nhưng đối với hầu hết các phần, bạn có thể gói gọn việc điều khiển logic mà UI phía sau ViewModel.

Bất kỳ dịch vụ nào bạn truy cập phải được bọc phía sau một giao diện (mẫu Mặt tiền) có khả năng di động nhiều hơn hoặc ít hơn giữa các nền tảng. Giao diện sẽ ánh xạ tới API khách của bạn ở mặt trước và dịch sang API của dịch vụ được bao bọc ở mặt sau.

Chiến lược này giúp bạn tạo ra một khung cốt lõi vững chắc, chỉ yêu cầu một giao diện người dùng mới được xếp chồng lên trên nó. Hãy nghĩ về nó như Mô hình xem của bạn là cơ bắp, các dịch vụ của bạn tạo ra bộ xương (và các cơ quan). WPF / Silverlight / WinRT tạo thành da.

Trên thực tế, một điều mà tôi chỉ ra rất sớm trong cuốn sách của mình là MVVM không mới như vẻ ngoài của nó. Cá heo Smalltalk có một mẫu tương tự mà họ gọi là MMVC (hai chữ M là Mô hình ứng dụng và Mô hình miền). ViewModel chúng tôi sử dụng ngày nay chỉ là sự kết hợp giữa Mô hình ứng dụng và Bộ điều khiển từ MMVC. Trong thực tế, nhiều nhà phát triển thấy rằng đôi khi tách ViewModel thành hai thành phần có ý nghĩa (bộ điều khiển được sử dụng để điều hướng và sắp xếp nhiều VM để VM có thể vẫn không biết về các thành phần khác).

Bạn nói XAML là vững chắc nhưng sau đó nói WPF có một tương lai đáng ngờ. Trừ khi tôi thiếu một cái gì đó, WPF sử dụng XAML và tôi không thấy hai người bị tách ra. Có một số tin tức tôi thiếu về WPF có thể sử dụng một số công nghệ cơ bản khác, hoặc về Microsoft thậm chí có thể xem xét xây dựng một cách mới khác để xây dựng UI? Ngoài ra, tôi nghi ngờ WPF sẽ đi bất cứ nơi nào, nhưng đây không phải là lần đầu tiên MS tải các mã lỗi của chúng tôi ...

Nếu bạn cần một ứng dụng UI phong phú và HTML5 sẽ không cắt nó và bạn đã cam kết với hệ điều hành windows, tôi nghĩ WPF là lựa chọn tốt nhất vì đây là ứng dụng cuối cùng / tuyệt vời nhất hiện nay, chắc chắn là trên winforms ...

Tôi đồng ý với điều này là bạn không nên tập trung quá nhiều vào các chi tiết triển khai ứng dụng của mình. Nếu bạn nhìn vào một bức tranh lớn hơn, bạn có thể cô lập các phụ thuộc công nghệ của mình. Bằng cách cách ly sự phụ thuộc vào ví dụ xaml / wpf / silverlight, bạn đảm bảo rằng bạn có thể thay thế thành phần / công nghệ ui bằng công nghệ thế hệ tiếp theo và do đó đảm bảo tính liên tục ngay cả trong 20 năm. Điều này cũng sẽ giúp tách rời các thành phần hệ thống của bạn và điều trị tác động của việc phải thực hiện thay thế như vậy. (Trong trường hợp này, tôi đưa ra một giả định rằng để cung cấp tính liên tục, bạn có thể tìm ra giải pháp để đưa nó đi trên nền tảng thế hệ tiếp theo)

Một cách khác để cung cấp sự tách biệt khỏi các phụ thuộc công nghệ này là cho phép ảo hóa. Nếu bạn tạo các ứng dụng của mình theo cách mà bạn có thể chạy chúng trong vm, bạn sẽ có thể làm như vậy trong 20 năm!