Выполнимость общего кода между.NET и Silverlight?
Только что пройдя небольшую сессию экспериментирования, чтобы попытаться видеть, сколько работы потребовалось бы для обеспечения нашей библиотеки классов.NET или по крайней мере части ее, в Silverlight так, чтобы мы могли снова использовать бизнес-логику между этими двумя мирами, я задаюсь вопросом, есть ли у других опыт с этим видом вещи.
Вещи я заметил, первое, что пришло на ум:
- Много пропавших без вести атрибутов (Доступный для просмотра (ложь), например)
- Много пропавших без вести интерфейсов или подарок, но пустой (ICloneable скрыт, пропавшие без вести ITypedList),
- Отражательные различия (все достижимые потребности быть общедоступным)
- Некоторые различия в базовом классе (никакой Компонент?)
Таким образом, я задаюсь вопросом, действительно выполнимо для меня даже посмотреть на это как на возможность?
Я получил начальное выполнение кода, но я должен был просто прокомментировать большую базовую функциональность, главным образом вокруг обработки списков, так как они основаны на ITypedList и некоторых базовых классах. По-видимому, я должен измениться на ObservableCollection в Silverlight, таким образом, весь из основного кода должен быть изменен для привыкания.
Фактический бизнес-тестовый класс, который я создал, на 99,5% идентичен тому, который я сделал бы для.NET, только некоторые незначительные изменения, которые легко будут применимы в.NET также, просто не, поскольку я сделал бы его перед рассмотрением Silverlight. Другими словами, выглядит выполнимым совместно использовать бизнес-логику, если я могу сделать базовые классы совместимыми.
Именно так я ясен, о чем я говорю, то, что у меня в основном было бы два файла проекта, один для.NET, и один для Silverlight, но фактический исходный код C# будет тем же, совместно использованным двумя.
У кого-либо есть опыт с этим? Какие-либо подсказки или инструкции?
Это будет стоить того? Это, конечно, гарантирует больше изучения.
4 ответа
Это определенно осуществимо.
Это сделано в проекте здесь; Проект Silverlight включает в себя C #, и есть некоторые #if утверждение, обрабатывающие некоторые вещи (например, log4net Декларации), а в других случаях все время просто повторяются. Но в целом это огромная победа, и вы обязательно должны попытаться (и, конечно, у нас успешно).
- Редактировать:
Одна точка, хотя, в том, что наша или / m (llblgen) не имел встроенной поддержки для «простых» объектов для отправки через Silverlight; Но кто-то написал плагин, который обрабатывал его, который помог. Таким образом, возможно, стоит рассмотреть, что вы используете DAL, и насколько хорошо он поддерживает Silverlight.
Что я сделал, чтобы облегчить это:
- Частое использование частичных классов и #if! Silverlight Чтобы отделить код на части, которые могут обрабатывать Silverlight.
- Использование генерации кода, когда это возможно. Например, я экспериментирую с шаблонами T4, которые генерируют эквивалентные атрибуты Silverlight (DisplayTtribute вместо описания, например)
- всякий раз, когда есть интерфейс / атрибут, который не реализуется Silverlight (например, IDeserializationCallback, Iclonable, inotifyPropertyChanging) Создайте фигурную интерфейс того же имени в приложении Silverlight до тех пор, пока я знаю, что тот факт, что реализация не будет использоваться, не проблема.
- Наконец, стоит отметить, что в Silverlight 4 формат сборки позволяет совместно использовать двоичные файлы между Silverlight и .NET до тех пор, пока нет зависимостей, которые не поддерживают Silverlight.
Еще одна заметка об отдельных базовых классах - может стоить создать абстрактный класс, который вытекает из наблюдательного элемента в Silverlight и BindingList (или что вы используете в .NET), чтобы минимизировать влияние на ваши типизированные коллекции.
Обновление Сегодня я работал над портированию некоторых .NET-код для Silverlight, который стал тяжелым использованием системной системы API. Я создал очень минимальные реализации этих в проекте Silverlight и поместите их в пространство имен Einstein.Diagnostics. При этом я решил, что мне нужна конвенция, чтобы легко определить код, который подражал .NET Framework vs. Мой собственный код. Поэтому я переименовал файлы заполнителей для префикса их с помощью знака @. Я также префиксировал названия классов в этих файлах. Приятно в том, что знак @ на самом деле не изменит имена своих классов, насколько касается компилятора C #. Так что @Sourceswitch все еще компилируется, чтобы быть Einstein.diagnostics.sourceswitch, но в коде я могу легко увидеть что-то. Я также украсил эти классы с атрибутом [SilverLightshollerHolder].
Одним из возможных исправлений к вашей проблеме - скопировать отсутствующий код из проекта MONO. В тот день, когда я сделал небольшой проект с компактной структурой, и она пропустила все пространство имен System.xlm. Я только что скопировал всю вещь от моно в моем проекте, составил его, и он отлично сработал с минимальными изменениями, IIRC.
Я делаю это с ProtoBuf-Net, и я использую несколько подходов:
- Условные символы компиляции в файле проекта, чтобы вызвать тонкие кодовые ветви (да, это не идеально, но это работает)
- повторное внедрение некоторых вещей; Атрибуты могут быть примером здесь - Ваш код все еще может использовать повторные атрибуты, даже если рамочный код не работает; В качестве более экстремального примера этого для компактных рамок я должен был повторно представить хороший кусок экспрессии
- , просто бросьте некоторые вещи ;-P
Однако Если вы используете ITypedList (который вы упоминаете), я могу видеть, что весь этот подход не разделяет довольно мрачно; Компонент-модель уже достаточно сложна, без необходимости принуждать к халанкам. Это действительно зависит от того, как далеко вы спустились по этой дороге. Может быть, 4.0 / Dynamic снова откроет некоторые из этих вариантов?