Возможность совместного использования кода между .NET и Silverlight?

Question

Только что проведя небольшой экспериментальный сеанс, чтобы попытаться увидеть, сколько потребуется работы, чтобы перенести нашу библиотеку классов .NET или, по крайней мере, ее части, в Silverlight, чтобы мы могли повторно использовать бизнес-логику между двумя мирами, Мне интересно, есть ли у других опыт такого рода вещей.

Вещи, которые я заметил, с макушки головы:

• Отсутствует много атрибутов (например, просматривается (false))
• Множество интерфейсов отсутствует или присутствует, но пусто (ICloneable скрыт, ITypedList отсутствует)
• Различия в отражении (все достижимое должно быть общедоступным)
• Некоторые различия базового класса (без Компонента?)

Так что мне интересно, реально ли мне даже взглянуть на это как на возможность?

Я запустил исходный код, но мне пришлось просто закомментировать целый ряд базовых функций, в основном связанных со списками, поскольку они основаны на ITypedList и некоторых базовых классах. Очевидно, мне нужно перейти на ObservableCollection в Silverlight, поэтому для того, чтобы справиться с этим, необходимо изменить весь базовый код.

Фактический класс бизнес-тестов, который я создал, на 99,5% идентичен тому, который я сделал бы для .NET, только некоторые незначительные изменения, которые можно было бы легко использовать и в .NET, только не так, как я бы это сделал прежде чем смотреть на Silverlight. Другими словами, представляется возможным обмениваться бизнес-логикой, если я могу сделать базовые классы совместимыми.

Просто, чтобы понять, о чем я говорю, это то, что у меня будет два файла проекта, один для .NET и один для Silverlight, но фактический исходный код C # будет таким же, что и общий два.

Так у кого-нибудь есть опыт с этим? Любые советы или рекомендации?

Это будет стоить того? Это, безусловно, заслуживает большего изучения.

Answer 1

Что я сделал, чтобы облегчить это:

1. Частое использование частичных классов и #if! SILVERLIGHT для разделения кода на части, которые может обрабатывать Silverlight.
2. Использование генерации кода при любой возможности. Например, я экспериментировал с шаблонами T4, которые генерируют эквивалентные атрибуты Silverlight (например, DisplayAttribute вместо DescriptionAttribute)
3. Всякий раз, когда есть интерфейс / атрибут, который не реализован Silverlight (например, IDeserializationCallback, ICloneable, INotifyPropertyChanging), я буду создавать фиктивный интерфейс с тем же именем в приложении Silverlight, если я знаю, что тот факт, что реализация не будет использоваться не проблема.
4. Наконец, стоит отметить, что в Silverlight 4 формат сборки позволяет совместно использовать двоичные файлы между Silverlight и .NET, если нет зависимостей, которые Silverlight не поддерживает.

Еще одно замечание об отдельных базовых классах - может быть целесообразно создать абстрактный класс, производный от ObservableCollection в Silverlight и BindingList (или что бы вы ни использовали в .NET), чтобы минимизировать влияние на ваши типизированные коллекции.

UPDATE Сегодня я работал над переносом некоторого кода .NET на Silverlight, который активно использовал API-интерфейсы System.Diagnostics, такие как TraceSource, SourceSwitch и т. Д., Которых нет в Silverlight. Я создал очень минимальные реализации их в проекте Silverlight и поместил их в пространство имен Einstein.Diagnostics. При этом я решил, что мне нужно соглашение, чтобы легко идентифицировать код, который имитирует .NET Framework и мой собственный код. Поэтому я переименовал файлы-заполнители, добавив в них префикс @. Я также добавил префиксы к именам классов в этих файлах. Хорошая вещь в этом заключается в том, что знак @ на самом деле не меняет своих имен классов, что касается компилятора C #. Таким образом, @SourceSwitch по-прежнему компилируется в Einstein.Diagnostics.SourceSwitch, но в коде я легко вижу, что что-то не так. Я также украсил эти классы атрибутом [SilverlightPlaceholder].

Answer 2

Это определенно возможно.

Это сделано для проекта здесь; проект Silverlight включает в себя C #, и есть некоторые операторы #IF, которые обрабатывают некоторые вещи (например, объявления log4net), а в других случаях вещи просто повторно реализуются. Но в целом это огромная победа, и вы обязательно должны попытаться (и, конечно, у нас это получилось).

- Изменить:

Однако следует отметить, что в нашем OR / M (LLBLGen) не было встроенной поддержки «простых» объектов для отправки через Silverlight; но кто-то написал плагин, который обработал его, что помогло. Поэтому, возможно, стоит подумать, какой DAL вы используете, и насколько хорошо он поддерживает Silverlight.

Answer 3

Одним из возможных решений проблемы является копирование отсутствующего кода из проекта Mono. Когда-то я делал небольшой проект с Compact Framework, и в нем отсутствовало все пространство имен System.XLM. Я просто скопировал всю вещь из Mono в свой проект, скомпилировал ее, и она отлично работала с минимальными изменениями, iirc.

Answer 4

Я делаю это с protobuf-net и использую несколько подходов:

• условные символы компиляции в файле проекта для запуска тонких ветвей кода (да, это не идеально, но работает)
• повторное введение некоторых вещей; атрибуты могут быть примером здесь - ваш код все еще может использовать повторно введенные атрибуты, даже если код платформы не делает; В качестве более яркого примера этого для компактной среды мне пришлось заново представить хороший кусок API Expression, что было забавно
• просто брось некоторые вещи; -p

Однако если вы используете ITypedList (который вы упоминаете), я вижу, что весь этот подход довольно беспорядочно разваливается; Компонент-модель уже достаточно сложен, без необходимости проходить через хаки. Это действительно зависит от того, как далеко вы пошли по этому пути. Может быть, 4.0 / dynamic снова откроет некоторые из этих опций?