Tính khả thi của mã được chia sẻ giữa .NET và Silverlight?

Question

Chỉ cần trải qua một phiên thử nghiệm nhỏ để thử xem sẽ tốn bao nhiêu công sức để mang thư viện lớp .NET của chúng ta, hoặc ít nhất một phần của nó vào Silverlight để chúng ta có thể tái sử dụng logic nghiệp vụ giữa hai thế giới. 'm tự hỏi nếu những người khác có kinh nghiệm với loại điều này.

Những điều tôi nhận thấy, ra khỏi đỉnh đầu của tôi:

• Rất nhiều thuộc tính thiếu (Có thể xem (false) ví dụ)
• Rất nhiều giao diện mất tích, hay hiện tại, nhưng rỗng (ICloneable là ẩn, ITypedList thiếu)
• khác biệt Reflection (nhu cầu có thể truy cập tất cả mọi thứ để được công khai)
• Một số khác biệt lớp cơ sở (không Component?)

Vì vậy, tôi tự hỏi, có thực sự khả thi đối với tôi thậm chí xem xét điều này như một khả năng?

Tôi nhận được mã ban đầu đang chạy, nhưng tôi phải bình luận rất nhiều chức năng cơ sở, chủ yếu là xung quanh danh sách xử lý vì chúng dựa trên ITypedList và một số lớp cơ sở. Rõ ràng tôi cần thay đổi thành ObservableCollection trong Silverlight, vì vậy cần phải thay đổi toàn bộ mã cơ sở để đối phó.

Lớp thử nghiệm kinh doanh thực tế mà tôi đã tạo là 99,5% giống như tôi đã tạo cho .NET. Chỉ một số thay đổi nhỏ có thể dễ dàng sử dụng được trong .NET, không giống như tôi đã làm trước khi xem Silverlight. Nói cách khác, có vẻ khả thi để chia sẻ logic nghiệp vụ, miễn là tôi có thể làm cho các lớp cơ sở tương thích.

Chỉ cần tôi rõ ràng, những gì tôi đang nói đến là về cơ bản tôi có hai tệp dự án, một cho .NET và một cho Silverlight, nhưng mã nguồn C# thực tế sẽ giống nhau, được chia sẻ giữa cả hai.

Vì vậy, có ai có kinh nghiệm với điều này không? Bất kỳ lời khuyên hay hướng dẫn nào?

Nó có đáng không? Nó chắc chắn đảm bảo nhiều hơn nhìn vào.

Answer 1

Điều này chắc chắn khả thi.

Nó được thực hiện trên một dự án ở đây; dự án Silverlight bao gồm các câu lệnh C#, và có một số câu lệnh #IF xử lý một số thứ (như khai báo log4net) và các lần khác chỉ được triển khai lại. Nhưng nói chung, đó là một chiến thắng lớn, và bạn chắc chắn nên thử nó (và chắc chắn, chúng tôi có, thành công).

- Chỉnh sửa:

Một điểm tuy nhiên, là chúng ta HOẶC/M (LLBLGen) không có hỗ trợ sẵn có cho 'đơn giản' đối tượng để gửi xuống qua Silverlight; nhưng ai đó đã viết một plugin để xử lý nó, điều này đã giúp. Vì vậy, nó có thể là giá trị xem xét những gì loại DAL bạn đang sử dụng, và làm thế nào nó hỗ trợ Silverlight.

Answer 2

Những gì tôi đã làm để tạo điều kiện này là:

1. thường xuyên sử dụng các lớp học phần và # nếu Silverlight để tách mã vào phần mà Silverlight có thể xử lý.
2. Sử dụng tạo mã bất cứ khi nào có thể.Ví dụ tôi đã thử nghiệm với các mẫu T4 tạo thuộc tính tương đương Silverlight (DisplayAttribute thay vì DescriptionAttribute chẳng hạn)
3. Bất cứ khi nào có giao diện/thuộc tính không được Silverlight thực hiện (chẳng hạn như IDeserializationCallback, ICloneable, INotifyPropertyChanging) tạo một giao diện giả của cùng một tên trong ứng dụng Silverlight miễn là tôi biết rằng thực tế rằng việc triển khai sẽ không được sử dụng không phải là một vấn đề.
4. Cuối cùng, cần lưu ý rằng trong Silverlight 4, định dạng lắp ráp cho phép chia sẻ các tệp nhị phân giữa Silverlight và .NET miễn là không có sự phụ thuộc mà Silverlight không hỗ trợ.

Một lưu ý nữa về các lớp cơ sở riêng biệt - bạn có thể tạo một lớp trừu tượng có nguồn gốc từ ObservableCollection trong Silverlight và BindingList (hoặc bất kỳ thứ gì bạn đang sử dụng trong .NET) để giảm thiểu tác động của bạn bộ sưu tập.

CẬP NHẬT Hôm nay tôi đã làm việc trên porting một số mã NET để Silverlight khiến dụng một lượng lớn System.Diagnostics của API như TraceSource, SourceSwitch, vv mà không tồn tại trong Silverlight. Tôi đã tạo ra những triển khai rất nhỏ trong các dự án Silverlight và đặt chúng vào không gian tên Einstein.Diagnostics. Khi làm như vậy, tôi quyết định tôi cần một quy ước để dễ dàng xác định mã đã bắt chước .NET Framework so với mã của riêng tôi. Vì vậy, tôi đổi tên các tập tin giữ chỗ để tiền tố chúng với một dấu @. Tôi cũng đặt trước tên lớp trong các tệp đó. Điều tốt đẹp về điều đó là dấu @ không thực sự thay đổi tên lớp của chúng theo như trình biên dịch C# có liên quan. Vì vậy, @SourceSwitch vẫn biên dịch để được Einstein.Diagnostics.SourceSwitch nhưng trong mã tôi có thể dễ dàng nhìn thấy một cái gì đó là lên. Tôi cũng đã trang trí các lớp này với thuộc tính [SilverlightPlaceholder].

Answer 3

Tôi làm điều này với protobuf-net, và tôi sử dụng một vài phương pháp:

• ký tự biên soạn có điều kiện trong hồ sơ dự án để kích hoạt tinh tế mã chi nhánh (có, nó không phải là hoàn hảo, nhưng nó hoạt động)
• giới thiệu lại một số thứ; các thuộc tính có thể là ví dụ ở đây - mã của bạn vẫn có thể sử dụng các thuộc tính được giới thiệu lại, ngay cả khi mã khung không; là một ví dụ cực đoan hơn về điều này, đối với khuôn khổ nhỏ gọn tôi phải tái giới thiệu một đoạn tốt đẹp của Expression API, đó là niềm vui
• chỉ cần thả một số điều ;-p

Tuy nhiên nếu bạn là sử dụng ITypedList (mà bạn đề cập đến), tôi có thể thấy rằng toàn bộ cách tiếp cận rơi ra ngoài khá lộn xộn; mô hình thành phần đã đủ phức tạp rồi, mà không phải ép buộc theo cách của bạn thông qua hacks nữa. Nó thực sự phụ thuộc hoàn toàn như thế nào đến nay bạn đã đi xuống con đường này. Có lẽ 4.0/dynamic sẽ mở lại một số tùy chọn này?

Answer 4

Có thể khắc phục được sự cố của bạn là sao chép mã bị thiếu trong dự án Mono. Quay trở lại trong ngày, tôi đã làm một dự án nhỏ với Compact Framework và nó đã thiếu toàn bộ không gian tên System.XLM. Tôi chỉ cần sao chép toàn bộ điều từ Mono vào dự án của tôi, biên dịch nó và nó làm việc tuyệt vời với những thay đổi tối thiểu, iirc.