Silverlight có phù hợp với giao diện người dùng sản phẩm dựa trên web của doanh nghiệp không?


8

Nhóm của chúng tôi hiện đang làm việc để xây dựng thế hệ tiếp theo của chúng tôi (Hệ thống thông tin bệnh viện) gồm hơn 30 mô-đun (hiện được ước tính là 400 tháng), có thể được lưu trữ ở một vị trí trung tâm và được truy cập trên các khu vực địa lý. Do đó, các NFR UI chính (Yêu cầu không chức năng) sẽ là

  • Tương thích nhiều trình duyệt
  • Tải trang nhanh với GUI phong phú
  • Khả năng tích hợp với các thiết bị phần cứng như máy quét sinh trắc học, đầu đọc sinh trắc học, v.v.
  • Dễ phát triển, bảo trì (kết hợp thay đổi), chu kỳ phát triển ngắn hơn
  • Khả năng mở nhiều biểu mẫu trong cùng một cửa sổ trình duyệt (không khởi chạy thêm các cửa sổ)

Ưu điểm:

  1. Giao diện người dùng sẽ không tin tưởng vào trình duyệt , chúng tôi không phải lo lắng về việc đảm bảo rằng các trang web của chúng tôi hoạt động với IE 7, 8, 9 ++ / Chrome 8, 9, 18 ++ / Mozilla Firefox (hiện tại có rất nhiều nỗ lực phát triển. kiểm tra và sửa lỗi tương thích)
  2. Chúng tôi có thể làm cho ứng dụng của mình trở nên mô đun hơn, không giống như ứng dụng ASP.Net nguyên khối
  3. Sử dụng bộ nhớ bị cô lập trên PC khách

Nhược điểm:

  1. Vấn đề rò rỉ bộ nhớ Silverlight. Chúng tôi đã đối mặt với chúng trong một vài mẫu mà chúng tôi đã xây dựng bằng SL và có cùng một vấn đề trong ứng dụng XBAP cũ. Các liên kết sau đây, chứng minh sự sợ hãi http://deefbrion.com/blog/2010/08/silverlight-getting-worse-when-it- results-to-memory-leaks / /programming/5091636 / silverlight-4-memory-rò rỉ

  2. Microsoft không xuất hiện rất nhiều về tương lai SL. Họ dường như đang đầu tư nhiều hơn vào HTML 5. Các bản phát hành SL 5 hoặc 6 trong tương lai cũng không chắc chắn. http://support.microsoft.com/gp/lifean45 http://www.zdnet.com/blog/microsoft/microsoft-our-strargety-with-silverlight-has-shifted/7834 http: //www.zdnet. com / blog / microsoft / will-there-be-a-silverlight-6-and-does-it-problems / 11180

  3. Các mô-đun NGÀI sẽ mở dưới dạng nhiều tab trong cùng một cửa sổ trình duyệt (chúng tôi đang nói về tối đa 8 tab mở cùng một lúc). Bao nhiêu tải sẽ được đặt vào phiên bản trình duyệt đó và nó sẽ ảnh hưởng đến vấn đề rò rỉ bộ nhớ như thế nào?

  4. Học đường cho các nhà phát triển ASP.Net

  5. Một liên kết ngăn xếp khác trên SL /programming/251718/silverlight-wpf-web-app-xbap-or-click-once-pros-and-cons

Trung tính

  1. Khả năng tương thích SEO không phải là một mối quan tâm

Truy vấn của tôi là?

  1. Bạn có sử dụng SL không, biết những ưu và nhược điểm trên (và khác)
  2. Trong trường hợp chúng tôi sử dụng mẫu MVVM để xây dựng một sản phẩm với SL làm mặt trước, có thể thay thế UI vào ngày mai bằng một UI khác (ASP.Net hoặc một cái gì khác). Hiểu biết của tôi là làm lại sẽ là đáng kể. Cộng đồng nghĩ gì?
  3. Chúng tôi đã dành một thời gian đáng kể trong phân tích trên (và trong việc tạo ra bằng chứng về các khái niệm). Có một yếu tố quan trọng / quyết định mà chúng ta đang xem xét?

Xin đừng đánh dấu đây là một bản sao, vì rất nhiều nghiên cứu và nỗ lực đã đi vào bài tập này.

Tái bút: Chúng tôi đã dành 6 tháng qua để xây dựng sản phẩm bằng các biểu mẫu web của ASP.Net (sử dụng mẫu MVP) và hiện đang xem xét sự thay đổi công nghệ vì những lý do trên.


1
Như @Alex nhấn mạnh, dòng "Khả năng tích hợp với các thiết bị phần cứng như máy quét sinh trắc học, đầu đọc sinh trắc học, v.v." có thể gây hiểu lầm và khó khăn Hãy bỏ qua rằng nếu bạn thích, mặc dù chúng tôi vẫn có nó dưới dạng NFR.

2
Không có thứ gọi là "đặt cược an toàn" khi chúng ta không biết tương lai sẽ mang lại điều gì. Vấn đề lớn nhất tôi thấy là sự phụ thuộc vào tích hợp phần cứng. Thành thật mà nói: Tôi sẽ dùng một ứng dụng máy tính để bàn cổ điển khi tích hợp phần cứng là chìa khóa.
Erno

Bạn đã không đưa ra đủ lý do tại sao bạn muốn từ bỏ công nghệ hiện tại (ASP.NET) sang một công nghệ khác mà nhân viên của bạn không được đào tạo và điều đó có một tương lai đáng ngờ. Dù sao, nếu bạn đang xây dựng một hệ thống có kích thước đó, trong thời đại ngày nay và bạn sẵn sàng đầu tư vào đào tạo, hãy sử dụng các công nghệ truyền phát chính trên giao diện người dùng như HTML5 và JavaScript. Không có công nghệ mặt trước sẽ tồn tại lâu dài.
NoChance

Câu trả lời:


2

Chúng tôi đã thực tế vấn đề này. Chúng tôi bắt đầu phát triển trên Silverligth. Đây là một công nghệ tốt, nhưng có lẽ Microsoft đã từ bỏ. Vì vậy, chúng tôi thay đổi để phát triển trên ASP.NET MVC.

Vì thế :

  1. Có lẽ không hoạt động trong metro Windows 8. Không hoạt động trên hệ điều hành khác.
  2. Rất khó để thay đổi Mẫu MVVM sang công nghệ khác. Đối với trường hợp của chúng tôi, thay đổi thành MVC với HTML 5 thay đổi tất cả mã.
  3. ...

Tôi hy vọng có thể giúp bạn.


1
-1 Câu trả lời này không nhiều thông tin. # 1 là sai trên hai số đếm. Đối với một, Silverlight chắc chắn sẽ được hỗ trợ trong Windows 8. Thứ hai, Silverlight cũng hoạt động trên Mac. # 2 là nhận thức. Nếu ứng dụng của bạn được cấu trúc đúng (MVVM, MVC, bất cứ điều gì), việc thay đổi các tầng sẽ dễ dàng hơn một chút. Dù bằng cách nào, nó sẽ trở nên khó khăn trong thế giới thực. # 3 không phải là một lý do ...
Morgan Herlocker

Hiểu biết của tôi là Windows 8 có 2 chế độ. Một trong những chế độ đó sẽ có IE không cho phép bổ trợ, nhưng chế độ khác sẽ cho phép các trình duyệt chạy plugin.
NoChance

2

Để trả lời một vài câu hỏi của bạn:

Các mô-đun NGÀI sẽ mở dưới dạng nhiều tab trong cùng một cửa sổ trình duyệt (chúng tôi đang nói về tối đa 8 tab mở cùng một lúc). Bao nhiêu tải sẽ được đặt vào phiên bản trình duyệt đó và nó sẽ ảnh hưởng đến vấn đề rò rỉ bộ nhớ như thế nào?

Tại sao bạn cần phải mở 8 tab cùng một lúc? Với Silverlight, bạn có thể có một tab ứng dụng duy nhất và tất cả các điều khiển / trang vv được gắn thẻ trong đó. Điều này sẽ không gây căng thẳng lớn hơn cho phiên bản trình duyệt và không làm cho vấn đề rò rỉ bộ nhớ trở nên tồi tệ hơn.

Trong trường hợp chúng tôi sử dụng mẫu MVVM để xây dựng một sản phẩm với SL làm mặt trước, có thể thay thế UI vào ngày mai bằng một UI khác (ASP.Net hoặc một cái gì khác). Hiểu biết của tôi là làm lại sẽ là đáng kể. Cộng đồng nghĩ gì?

Hầu như bất kỳ công nghệ nào bạn chọn bây giờ cũng sẽ khiến bạn đau đầu như vậy nếu bạn cố gắng thay thế UI. Trừ khi bạn hoàn toàn có thể ly dị logic ứng dụng khỏi UI, sẽ có việc làm lại chính liên quan. Ít đau nhất sẽ xảy ra nếu bạn chuyển đổi nó thành ứng dụng WPF.

Tuy nhiên, tuyên bố này:

Khả năng tích hợp với các thiết bị phần cứng như máy quét sinh trắc học, đầu đọc sinh trắc học, v.v.

khiến tôi nghĩ rằng việc sử dụng bất kỳ công nghệ dựa trên web nào sẽ gây ra cho bạn các vấn đề trong lĩnh vực này. Ở đây tôi đồng ý với Alex - đặt cược tốt hơn có thể là viết một ứng dụng gốc. Sử dụng Java sẽ cung cấp cho bạn một số khả năng tương tác trên nhiều nền tảng, nhưng với chi phí không sử dụng các yếu tố UI gốc.


Xin lỗi, nếu mục tiêu tab không rõ ràng. Chúng tôi đang cố gắng mở nhiều tab trong cùng một ứng dụng SL. Ứng dụng cơ sở (không có tab bên trong) bắt đầu với bộ nhớ 50 MB trong trình quản lý tác vụ và khi mở khoảng 15 tab (với các điều khiển biểu mẫu khác nhau và không có logic xử lý), bộ nhớ đã bắn lên tới 250 + MB. Khi đóng tất cả các tab, việc giảm bộ nhớ đã giảm nhưng cuối cùng vẫn ở mức 150MB. Do đó, mặc dù có nhiều tab trên một ứng dụng có thể chạy 24 giờ một ngày (không đăng xuất) đang được nghĩ lại. Hoàn toàn đồng ý về nỗi đau nâng cấp UI.
Tushax

1

Khả năng tích hợp với các thiết bị phần cứng như máy quét sinh trắc học, đầu đọc sinh trắc học, v.v.

Cái này có thể khó và sẽ yêu cầu chế độ OutOfBrowser cho Silverlight, bạn sẽ phải sử dụng COM để làm việc này và điều này sẽ làm hỏng yêu cầu trình duyệt chéo của bạn. COM chỉ hoạt động trong Internet Explorer.

IMHO yêu cầu khó khăn nhất cho ứng dụng WEB là làm việc với các thiết bị bên ngoài. Thông thường họ đi kèm với các thư viện C, C ++ để làm việc với họ và bạn cần một cách để xen vào C, C ++.

Tôi không nghĩ rằng các yêu cầu này có thể được thỏa mãn bởi bất kỳ công nghệ WEB nào, chỉ khi các applet Java, nhưng tôi không biết về các khả năng của các applet java. Theo bất kỳ cách nào tôi sẽ nghĩ về Java, ứng dụng applet hoặc máy tính để bàn, tùy thuộc vào khả năng làm việc với phần cứng.


Có Alex, trước đây đã có những vấn đề với các điều khiển OCX (Activex): chúng chỉ là IE

0

Nếu JS không liên quan đến bạn, tôi sẽ sử dụng Html5 + JS. Không yêu cầu plugin bên ngoài, IE cũ có thể được tạo ra để lý do với Html5 thông qua JS và nó cũng sẽ hoạt động trên các thiết bị di động.

SL như Flash yêu cầu plugin, sẽ không hoạt động trên thiết bị di động, v.v.

Nếu bạn thích mẫu MVVM, bạn có thể kết hôn với Html5 với Knockout.js, một thư viện JS sử dụng mẫu MVVM, tôi đã sử dụng nó trong một vài dự án và thật tuyệt vời.

Vì vậy, để trả lời, hãy tránh xa SL hoặc Flash nếu bạn muốn thứ gì đó tương thích và nhanh nhất có thể.


1
SilverLight không hoạt động trên một số thiết bị di động. Ngoài ra, JavaScript có thể khá áp đảo tùy thuộc vào ứng dụng khách thực thi nó. Thật vô lý khi nghĩ rằng HTML và JS sẽ luôn nhanh hơn.
Yuck

Như bạn nói, nó hoạt động trên "một số". Html5 + JS tương thích hơn nhiều. Tôi không phải là một fan hâm mộ lớn của JS nhưng anh ấy cần phía máy khách công cụ động, đó là plugin hoặc plugin và khả năng tương thích kém hơn.
Matteo Mosca

Làm thế nào bạn có được một giải pháp "thuần túy" như thế này mà không có plugin để làm việc với phần cứng bên ngoài?
Yuck

IMHO JS là một kỹ năng thích hợp mà theo thời gian có thể rất khó để giữ và duy trì. Đồng ý về phần chúng tôi sẽ yêu cầu các plugin để giao tiếp với phần cứng bên ngoài.
Tushax
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.