ASP.Net hoặc WPF (C #)? [đóng cửa]

Nhóm của chúng tôi chia rẽ về điều này và tôi muốn nhận được một số ý kiến ​​của bên thứ ba.

Chúng tôi đang xây dựng một ứng dụng và không thể quyết định xem chúng tôi muốn sử dụng .Net WPF Desktop Application với máy chủ WCF hay ứng dụng web ASP.Net bằng jQuery. Tôi nghĩ rằng tôi sẽ đặt câu hỏi ở đây, với một số thông số kỹ thuật, và xem những ưu / nhược điểm của việc sử dụng một trong hai bên sẽ là gì. Tôi có sự yêu thích của riêng tôi và cảm thấy tôi thiên vị.

Lý tưởng nhất là chúng tôi muốn xây dựng bản phát hành phần mềm ban đầu nhanh nhất có thể, sau đó làm chậm và dành thời gian để xây dựng các tính năng / thành phần bổ sung mà chúng tôi muốn sau này. Trên hết, chúng tôi muốn phần mềm được nhanh chóng. Người dùng trải qua các hồ sơ suốt cả ngày và sự chậm trễ trong việc tải hồ sơ hoặc làm mới màn hình sẽ giết chết năng suất của họ.

Chi tiết ứng dụng:

• Tôi đang ước tính khoảng 100 màn hình khác nhau cho phiên bản ban đầu, với kế hoạch cho rất nhiều màn hình bổ sung sẽ được thêm vào sau khi phát hành lần đầu.
• Chúng tôi đang tìm cách sử dụng giao tiếp hai chiều cho hệ thống nhắc nhở và sự kiện
• Hiện tại phải hỗ trợ khoảng 100 người dùng, mặc dù chúng tôi được cho phép tăng trưởng tới 500 người dùng
• Chúng tôi có nhiều địa điểm

Các mục cần xem xét (có thể không phải ban đầu trong một số trường hợp nhưng trong các phiên bản tương lai):

• Phòng cho các thành phần bổ sung được thêm vào sau khi phát hành ban đầu (có rất nhiều trong số này ... có lẽ hoạt động ở đây hơn ứng dụng ban đầu)
• Điều hướng bàn phím
• Hiệu suất là phải
• Tốc độ sản xuất đến phiên bản ban đầu
• Chi phí bảo trì thấp
• Hỗ trợ trong tương lai
• Tích hợp Softphone / Scanner

Nhà phát triển của chúng tôi:

• Chúng tôi có 1 lập trình viên đã học WPF vài tháng qua và là người đề nghị chúng tôi sử dụng WPF cho việc này.
• Chúng tôi có một lập trình viên thứ 2 quen thuộc với ASP.Net và có thể giúp đỡ cho dự án trong tương lai, mặc dù anh ấy sẽ không làm việc với nó cho đến khi phát hành ban đầu vì thời gian của anh ấy dành cho việc duy trì phần mềm hiện tại của chúng tôi.
• Có tôi, người đã làm việc với cả hai và cảm thấy thoải mái
• Chúng tôi có một công ty bên ngoài làm quản lý dự án và họ là một công ty ASP.Net.
• Chúng tôi dự định thuê 1-2 người khác, tuy nhiên chúng tôi cần biết chúng tôi sẽ đi theo hướng nào trước

Môi trường:

• Người dùng phổ thông đang ở trên máy chủ Windows 2003 với Terminal Services. Họ kết nối bằng các máy khách mỏng WYSE qua kết nối RDP. Nhân viên quản trị có PC riêng với XP hoặc cao hơn. Người dùng được phép chỉ định độ phân giải của riêng mình mặc dù họ bị giới hạn sử dụng IE làm trình duyệt web.
• Các vị trí khác kết nối với mạng của chúng tôi qua kết nối MPLS

Dựa vào đó, bạn sẽ chọn cái gì và tại sao?

Nó chắc chắn nghe giống như một ứng dụng WPF, với rất nhiều tương tác của người dùng và có khả năng tương tác với phần cứng. Bạn có thể phân phối ứng dụng qua Click-Again để việc triển khai chủ yếu là không thành vấn đề. Ứng dụng WPF của bạn có thể truy cập dịch vụ WCF và cung cấp dữ liệu dưới dạng nhị phân, do đó hiệu suất sẽ rất tuyệt vời. Tôi sẽ bắt đầu đọc lên WPF và làm quen với nó càng sớm càng tốt.

Lunatic fringe trả lời: cả hai. Có được lớp dịch vụ phù hợp, thật dễ dàng để có một máy khách dày làm mọi thứ (WPF) và một máy khách web nhanh để thực hiện hầu hết các việc phổ biến (ASP.NET). Lá cửa mở cho khách hàng di động, vv, xuống đường.

Nếu bạn chỉ có một lập trình viên đang học WPF và bạn đang cân nhắc việc nhóm của bạn chuyển sang WPF thì tại sao không sử dụng Silverlight thay thế? Bạn nhận được nhiều lợi thế của WPF nhưng vẫn duy trì khả năng rời khỏi dự án của bạn dưới dạng một ứng dụng web. Vì bạn đang xem xét có một dự án được mô đun hóa lớn, nên sử dụng PRISM với WPF hoặc Silverlight để làm cho MVVM đơn giản hơn.

Nhóm của tôi gần đây đã đưa ra lựa chọn sử dụng Silverlight trên asp.net. Nó đã là một sự lựa chọn tuyệt vời cho chúng tôi. Chúng tôi ban đầu chỉ có một nhà phát triển duy nhất biết bất kỳ ánh sáng bạc nào. Sau đó tất cả chúng tôi đã tham gia một lớp đào tạo trong tuần hầu như vô dụng, nhưng ít nhất là bị ướt chân. Cuối cùng, chúng tôi đã phải thuê hai nhà thầu để giúp chúng tôi tạo ra phần lớn khung UI. Phần lớn đội ngũ của chúng tôi vẫn không tự tin vào các kỹ năng bạc của họ. Bản thân tôi, thành viên nhóm ban đầu có kiến ​​thức về silverlight và hai nhà thầu là những người thực hiện phần lớn việc phát triển SL. Sau đó, chúng tôi có hai thành viên back-end chuyên dụng. Tôi sẽ nói rằng chúng tôi mất khoảng 2 tháng sau khi đưa ra quyết định chuyển sang Silverlight mà chúng tôi thực sự có bất cứ điều gì cụ thể. Tuy nhiên, bây giờ chúng tôi có một sản phẩm tuyệt vời có cảm giác rất giống ứng dụng phía máy khách đang chạy bên trong trình duyệt web và không được cài đặt trên bất kỳ máy nào tại địa phương. Sự phát triển đã được tổng cộng dưới một năm và chúng tôi gần sẵn sàng để phát hành hoặc ứng cử viên phát hành đầu tiên.

Một số điều cần xem xét:

• WPF hoặc silverlight, bất cứ điều gì bạn chọn sẽ có một số tiền hợp lý mà các nhà phát triển của bạn sẽ cần phải học.

• Silverlight có thể hết trình duyệt nếu cần. Nếu bạn làm điều này, việc cài đặt nó khá dễ dàng để nếu bạn tung ra một phiên bản mới thì chương trình SL đã cài đặt sẽ tự động cập nhật.

• Silverlight không bao gồm tất cả các điều khiển mà WPF có.

Lưu ý cuối cùng của tôi là nếu bạn muốn tạo ra mã càng nhanh càng tốt thì khá rõ ràng bạn nên dùng ASP.NET. Ưu điểm chính của tôi với ASP là trừ khi bạn kỷ luật nhóm của mình, rất dễ để một dự án ASP.NET trở nên lộn xộn và lộn xộn. Nếu bạn nghĩ rằng bạn sẽ có thể đối phó với chi phí ban đầu để tăng tốc với các công nghệ thì Silverlight hoặc WPF sẽ cho phép bạn rất nhiều khả năng tuyệt vời.

Phần này khá liên quan:

Người dùng phổ thông đang ở trên máy chủ Windows 2003 với Terminal Services. Họ kết nối bằng các máy khách mỏng WYSE qua kết nối RDP. Nhân viên quản trị có PC riêng với XP hoặc cao hơn. Người dùng được phép chỉ định độ phân giải của riêng mình mặc dù họ bị giới hạn sử dụng IE làm trình duyệt web.

WPF không tuyệt vời so với các kết nối máy khách Remote Desktop / Thin. Ảnh động sẽ không được mượt mà và bất kỳ hình ảnh phức tạp nào (thậm chí là độ dốc) sẽ làm chậm phản hồi UI xuống thu thập dữ liệu. Nhân viên quản trị với các máy retro XP điển hình cũng rất có thể gặp vấn đề về hiệu năng với các ứng dụng WPF phức tạp (vì số lượng RAM nhỏ và GPU xấu).

Nếu bạn đi theo lộ trình WPF để có đồ họa phong phú, hãy chuẩn bị cho các bản hack hiệu suất vào phút cuối khi bạn phát hiện ra rằng các máy mục tiêu đã mười năm tuổi. Bám sát màn hình tĩnh và sử dụng .NET 4.0 vì hiệu suất WPF đã được cải thiện đáng kể kể từ 3.5.

Về mặt kỹ thuật, tôi tin rằng sự kết hợp WPF / WCF là giải pháp tốt hơn.

Tuy nhiên, tôi không tin rằng lập trình viên WPF hiện tại của bạn thực sự có kinh nghiệm cho dự án này. WPF là một sự thay đổi trong quá trình suy nghĩ lập trình từ lập trình Winform và vì vậy bạn sẽ cần suy nghĩ lâu dài và chăm chỉ để bạn thực sự có đủ kỹ năng trong nhóm để đưa ra lộ trình này.

Hấp dẫn. Điều đó nghe có vẻ quen thuộc với một ứng dụng mà chúng tôi mới bắt đầu tại công ty của tôi (sip tích hợp điện thoại và máy quét và tất cả).

Chúng tôi đã chọn silverlight với trọng tâm là SOA để có thể tạo ra ứng dụng WPF sau đó nếu có nhu cầu.

Phòng cho các thành phần bổ sung được thêm vào sau khi phát hành ban đầu (có rất nhiều trong số này ... có lẽ hoạt động ở đây hơn ứng dụng ban đầu)

Chúng tôi đang sử dụng MEF trong lớp dịch vụ và xây dựng các điểm mở rộng (giao diện plugin mô tả một số điểm nhất định nơi chúng tôi lên kế hoạch mở rộng hoặc tích hợp với các hệ thống khác)

Điều hướng bàn phím

Không thành vấn đề.

Hiệu suất là phải

Những loại hiệu suất? Hiệu suất cảm nhận (snappy-ness) hoặc hiệu suất crunching số? Cái sau có thể là một vấn đề với ứng dụng web / silverlight. Trước đây, ứng dụng của chúng tôi trải qua rất nhiều hồ sơ, như của bạn, nhưng chúng tôi có thể dự đoán chúng và tìm nạp trước các bản ghi trong khi người dùng đang làm việc trên những bản ghi hiện tại. Thời gian 'Tải' bằng 0 cho phần đó trong ứng dụng của chúng tôi.

Tốc độ sản xuất đến phiên bản ban đầu

Phụ thuộc vào các kỹ năng. Nhưng thực tế, mọi người luôn muốn tiếp cận thị trường nhanh nhất có thể, vì vậy đó là một cuộc tranh luận.

Chi phí bảo trì thấp

Giống như tốc độ sản xuất, nó cũng không phải là một đối số và nó sẽ đi xuống để thực hành thiết kế và mã hóa. Nếu bạn đang nói về bảo trì phần cứng, bạn có thể muốn sử dụng ứng dụng đám mây.

Hỗ trợ trong tương lai

Tôi không chắc điều đó có nghĩa là gì.

Tích hợp Softphone / Scanner

Silverlight 4 cho phép truy cập webcam / mic ngay bây giờ (chúng tôi hy vọng sẽ thực hiện hội nghị video liên ứng dụng cũng như tích hợp sip), vì vậy nếu bạn đang sử dụng máy chủ điện thoại, bạn có thể tự viết. Tôi không biết bất kỳ cái nào hiện có, nhưng cái này có thể giúp ích.

Nếu không, bạn có thể phải thực hiện một số hack xấu xí (không có tài liệu tham khảo cho bài viết nữa, xin lỗi) hoặc bạn không có lựa chọn nào khác ngoài việc có một ứng dụng WPF có thể tương tác với hệ thống tệp. SL4 có thể ra khỏi trình duyệt, nhưng nó chỉ có thể truy cập vào một số phần nhất định của hệ thống tệp. Không ai trong số họ có thể sẽ là những phần mà bạn cần tương tác với một chiếc điện thoại.

Ý bạn là, máy quét tài liệu? Tôi không chắc về điều đó. Chúng tôi đang sử dụng máy quét mã vạch / tay và chúng hoạt động giống như bất kỳ thiết bị đầu vào nào khác và không phải là vấn đề.

Bạn có cần một ứng dụng cực kỳ nhạy bén để mọi người sử dụng cả ngày không? sử dụng WPF; bạn cũng sẽ dễ dàng sử dụng lại các thành phần GUI trong WPF hơn cả ASP / MVC (IMHO)

vâng, jquery et al rất tuyệt, silverlight rất tuyệt, nhưng các ứng dụng trên máy tính để bàn vẫn hiệu quả hơn

Đối với back-end, WCF vẫn ổn

Tôi sẽ phải khuyên bạn nên sử dụng WCF cho lớp dịch vụ của mình vì khả năng mở rộng và bảo mật. Đối với lớp trình bày, bạn có thể sử dụng Silverlight hoặc ASP.NET, Silverlight giống như Flash, nhưng ban đầu thật khó hiểu và có một đường cong học tập cao, chủ yếu là khi làm việc với dữ liệu. ASP.NET dễ sử dụng hơn nhưng bạn sẽ cần rất nhiều tinh chỉnh và javascript để sử dụng nó một cách hiệu quả.