Những yếu tố cần xem xét khi chọn thời gian chạy / ngôn ngữ cho các ứng dụng máy tính để bàn Windows?


10

Tất cả người dùng của tôi đều có Windows. Một số người trong số họ sử dụng Linux hoặc Mac, nhưng nếu họ thường có khả năng sử dụng thứ gì đó như Mono, Wine, Parallels hoặc dual-boot.

Nhóm phát triển của tôi (bao gồm cả bản thân tôi) có nhiều kinh nghiệm trong việc viết các ứng dụng Swing trong Java cũng như Windows Forms trong C #. "Mở rộng" có nghĩa là chúng tôi đã phát triển và chuyển giao hơn ba ứng dụng trên cả hai thời gian chạy. Các ứng dụng này là các ứng dụng phân tích kỹ thuật, rất nhẹ về tương tác cơ sở dữ liệu, nhưng nặng về giao diện người dùng và dữ liệu tùy chỉnh.

Chúng ta sẽ đến lúc chúng ta thực sự muốn đưa ra quyết định nên tập trung vào nền tảng nào kể từ bây giờ, vì nó trở thành gánh nặng để hỗ trợ cả hai (nếu bạn làm việc trong Swing trong nửa năm thì quá nhiều rắc rối để làm quen với Windows Forms một lần nữa và ngược lại) và chúng tôi muốn mọi người trong nhóm của chúng tôi có khả năng làm việc trên tất cả các ứng dụng của chúng tôi.

  • Windows Forms thường mất ít công sức hơn để làm cho các ứng dụng Windows dễ nhận biết. Không có số lượng điều khiển lột da và tùy chỉnh nào trong Java đã giải quyết điều đó trong nhiều năm qua. Đồng thời, chúng tôi chưa bao giờ có một khách hàng không thể sử dụng các ứng dụng Swing.
  • Java từng có một hệ sinh thái phong phú hơn nhiều về các thư viện và các công cụ xây dựng tự động, nhưng điều đó đang thay đổi nhanh chóng (Java sẽ không đi xuống, đó là điều mà .NET đang bắt kịp).
  • Đối với trường hợp hiếm hoi mà đa nền tảng được ưa thích, Java đánh bại .NET. Mono là tuyệt vời, nhưng nó vẫn hoạt động nhiều hơn Java.

Nếu chúng tôi chọn .NET, chúng tôi có thể bắt đầu tập trung vào WPF, nhưng cũng bắt đầu sử dụng F #. Nếu chúng ta chọn Java, chúng ta có thể bắt đầu tập trung vào RCP, nhưng cũng bắt đầu sử dụng Scala.

Có ai đã phải đưa ra một quyết định tương tự? Nếu vậy, nó là gì và điều gì ảnh hưởng đến bạn nhất? Bất kỳ mối quan tâm hàng đầu nào tôi đang thiếu?

(Xin lưu ý: đã có một số câu hỏi tương tự trên Lập trình viên. Đã có, nhưng chúng không có tính xây dựng hoặc từ một góc độ khác.)


2
Từ ý chính của việc đọc, tôi tin rằng tiêu đề câu hỏi phải là "Tôi nên nghĩ đến yếu tố nào khi chọn thời gian chạy / ngôn ngữ cho ứng dụng máy tính để bàn Windows?" , tập trung nhiều hơn vào khía cạnh ra quyết định của câu hỏi của bạn. Điều đó dễ trả lời hơn và ít lây nhiễm hơn "Tôi nên sử dụng cái gì?" - loại câu hỏi mà tiêu đề dường như ám chỉ.
Spoike

@Spoike Điểm tuyệt vời, tôi đã cập nhật tiêu đề (làm cho nó ngắn hơn một chút).
Deckard

1
Có thể liên kết này có một cái gì đó về tương lai của Windows, điều này rất quan trọng đối với các bạn IMHO- zdnet.com/blog/microsoft/ trộm
Gulshan

Buộc người dùng Mac cài đặt Wine và chạy ứng dụng Windows cũng giống như tra tấn họ.
đúng

Câu trả lời:


7

Chúng tôi đã sử dụng Java (Swing) cộng với một số phần gốc thông qua JNI. Mặc dù nhu cầu thương mại cho đa nền tảng ngày nay có thể không đáng kể, nhưng tình hình có thể khác trong 5 năm và vòng đời của ứng dụng (một ứng dụng đo lường khoa học) sẽ giống hơn 10 năm (tiền thân C ++, vẫn được sử dụng cho đến ngày nay, tập tin nguồn ngày 1991). Như bạn đã viết, Java đánh bại .NET xử lý trong các môi trường không phải Windows và nếu chúng ta cần phải rời khỏi Windows, thì đó chỉ là vấn đề biên dịch lại một số phần gốc, có thể tinh chỉnh giao diện GUI và kiểm tra xem làm tất cả mọi việc.

Nếu bạn chắc chắn bạn sẽ chỉ là Windows và ứng dụng của bạn sẽ tồn tại chỉ vài năm nữa, thì .NET có thể được ưa thích hơn - nó trông giống và hoạt động giống như một ứng dụng gốc hơn. Nhưng là một khoản đầu tư dài hạn, tôi tin tưởng Java hơn. Swing có thể trông hơi kém hoàn hảo, thời gian khởi động có thể lâu hơn, mọi thứ đều tối ưu một chút vì lớp trừu tượng đa nền tảng, nhưng ít nhất nó "chỉ hoạt động".


2
Theo cách nào thì một ứng dụng .NET giống một ứng dụng Windows gốc hơn Java?
Rei Miyasaka

@Rei: trong đó .NET framework chỉ có sẵn cho Windows. Chắc chắn, có mono, nhưng nó luôn bị tụt lại phía sau, và hiện tại tương lai của nó là, không chắc chắn.
Tamás Szelei

1
@ Tamás Đó là một vấn đề hoàn toàn khác. Ngoài một vài byte mã đầu tiên trong .exes in "Chương trình này không thể chạy trong chế độ DOS.", Chương trình vẫn hoàn toàn là mã byte. Một thư viện Java cũng giống như một thư viện .NET, ngay cả khi điều ngược lại có thể không đúng do thiếu triển khai.
Rei Miyasaka

4

Một điều bạn có thể muốn xem xét là dự án IKVM cho phép bạn sử dụng mã Java trong thế giới .NET. Sau đó, bạn có thể nhận được các lợi ích của một phụ trợ Java, trong khi - theo hiểu biết của tôi - bạn có thể có một trình duyệt phía trước mỏng trong cả Swing hoặc WinForms.

http://www.ikvm.net/

Tôi đã nghe nói rằng những người khác đã sử dụng điều này để sử dụng một thư viện kết nối nguồn mở được viết bằng Java từ .NET thay vì phải sử dụng phiên bản .NET cồng kềnh.


3

Có một tài nguyên trên MSDN có thể hữu ích cho bạn: http://msdn.microsoft.com/en-us/gg715299.aspx .

Nếu bạn đi đến cuối trang, bạn sẽ tìm thấy một loạt các trang trắng so sánh về mặt khái niệm Java và .NET. Tất nhiên vì trên MSDN, nó thiên về .NET, nhưng tài nguyên vẫn khá hữu ích.


1

Tôi cũng đã suy nghĩ về vấn đề này và tôi đã tìm thấy câu trả lời tùy thuộc vào loại dự án và những gì bạn có thể thấy trước về nó.

Đôi khi, tạo One Codebase để phục vụ tất cả các nền tảng là một điều tốt - bạn có được một số mức độ nhất quán UI với ít mã tổng thể hơn. Tôi nghĩ rằng những lợi thế và bất lợi là rõ ràng, vì vậy tôi sẽ bỏ qua điều đó.

Có những lúc có 2 cơ sở mã được viết là tốt hơn. Ví dụ, nếu viết ứng dụng của bạn trong WPF thì thanh lịch cho .NET và viết nó vào, giả sử, Cốc Cốc thanh lịch cho Mac OS, mã kết quả thực sự có thể nhỏ hơn so với sử dụng, giả sử, Java hoặc Mono (không có WPF). Trong trường hợp đó, bạn có thể nhận được kết quả tốt hơn với ít mã hơn.

Việc xem xét cuối cùng có lẽ là thực hiện ứng dụng của bạn dưới dạng ứng dụng HTML5 hoặc thậm chí là tiện ích mở rộng của Chrome, nhưng đó có thể là trường quá trái.


1

Bạn đã xem xét Silverlight chưa? Nó có thể là một lựa chọn tốt để xây dựng ứng dụng Windows Desktop (từ SL4 +) và hoạt động tốt trên Mac.


SL gần như đã chết ..
klm_

Microsoft không nghĩ vậy. Cá nhân tôi nghĩ rằng html5 là lựa chọn đầu tiên cho ứng dụng web nhưng SL phía khách có thể là một công nghệ tốt.
ADIMO

Tôi cũng sẽ dùng HTML5, vì nó được W3O hỗ trợ. Silverlight đang cạnh tranh với HTML5 và nếu nó không tạo được chỗ đứng thì nó sẽ chết, tôi nghĩ vậy.
klm_

1

Là một nhà phát triển Java toàn thời gian, tôi có thể nói với bạn rằng trong khi khả năng tương thích đa nền tảng là tuyệt vời, thì mọi tích hợp riêng đều là địa ngục .

Tôi luôn có nhiều vấn đề, và đôi khi thất bại, trên mặt đất này. Bạn có thể không cần nó, nhưng đôi khi tôi vấp phải nó và nó thường đau.

  • Tích hợp với COM là một nỗi đau và đôi khi COM + là không thể (lãng phí hàng tuần để cố gắng làm cho nó hoạt động với Windows Tablet API).
  • Tương tác phần cứng có thể làm tổn thương. Đôi khi API chỉ khả dụng trên một nền tảng (ví dụ: tích hợp máy ảnh / máy quét).
  • Tương tác với các ứng dụng cục bộ cũng có thể bị tổn thương. Tôi đã đề cập đến nỗi đau COM? Chà, một cách khác (mà chúng tôi thực sự đã sử dụng) là tạo và thực thi các tập lệnh VBS khởi chạy một ứng dụng Windows như MapPoint hoặc một số ứng dụng bản đồ độc quyền và cung cấp dữ liệu đó.
  • Cài đặt và tích hợp máy tính để bàn (phím tắt, trình gỡ cài đặt, menu bắt đầu) cũng có thể bị tổn thương. Web Start rất không đáng tin cậy. Các lựa chọn thay thế có thể khiến bạn phải trả giá đắt hoặc thiếu một số tính năng (như phân phối cập nhật).

Đừng hiểu lầm tôi. Tôi là một nhà phát triển Java và không có ý định kích hoạt nó. Tôi chỉ nói rằng nếu bạn nghi ngờ bạn sẽ cần bất kỳ điều nào ở trên, điều đó có thể gây tổn thương và bạn có thể tốt hơn với .net . Ít nhất đó là một lập luận mà bạn nên xem xét.

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.