C# NET和Silverlight之间共享代码的可行性？

我刚刚经历了一个小的实验环节，试图看看将我们的.NET类库（或至少部分类库）引入Silverlight需要做多少工作，以便我们可以在两个世界之间重用业务逻辑，我想知道其他人是否有这方面的经验

我注意到的事情，在我的脑海里：

• 缺少很多属性（例如可浏览（false））
• 大量接口缺失或存在，但为空（iClonable隐藏，ITypedList缺失）
• 反映差异（所有可访问的内容都需要公开）
• 一些基本类差异（无组件？）

所以我想知道，我真的可以把它看作一种可能性吗

我运行了最初的代码，但我不得不注释掉很多基本功能，主要是处理列表，因为它们基于ITypedList和一些基类。显然，我需要在Silverlight中更改为ObservableCollection，因此需要更改整个基本代码以应对这种情况

我创建的实际业务测试类与我为.NET所做的测试类有99.5%的一致性，只有一些小的更改可以很容易地在.NET中使用，只是不像我在查看Silverlight之前所做的那样。换句话说，如果我能使基类兼容，那么共享业务逻辑看起来是可行的

我很清楚，我要说的是，我基本上有两个项目文件，一个用于.NET，一个用于Silverlight，但实际的C#源代码是相同的，在两者之间共享

有没有人有过这样的经历？有什么建议或指南吗

---

值得吗？这当然需要更多的研究。

这绝对是可行的

这是在这里的一个项目上完成的；Silverlight项目包括C#one，有一些

#IF

语句处理一些事情（比如log4net声明），其他时候只是重新实现了一些事情。但总的来说，这是一场巨大的胜利，你绝对应该尝试一下（当然，我们已经成功了）

--编辑：

---

不过有一点是，我们的OR/M（LLBLGen）没有内置对通过Silverlight发送的“简单”对象的支持；但是有人写了一个插件来处理它，这很有帮助。因此，有必要考虑您正在使用哪种DAL，以及它对Silverlight的支持程度。

我为促进这一点所做的工作是：

频繁使用分部类和#if！SILVERLIGHT将代码分成SILVERLIGHT可以处理的部分

尽可能使用代码生成。例如，我一直在试验生成Silverlight等效属性的T4模板（例如DisplayAttribute而不是DescriptionAttribute）

只要有Silverlight未实现的接口/属性（如IDeserializationCallback、IClonable、InotifyPropertyChange），只要我知道不使用实现这一事实不是问题，我就会在Silverlight应用程序中创建一个同名的虚拟接口

最后，值得注意的是，在中，只要没有Silverlight不支持的依赖项，汇编格式就允许在Silverlight和.NET之间共享二进制文件

关于独立基类的另一个注意事项是：创建一个抽象类，该抽象类派生自Silverlight和BindingList中的ObservableCollection（或您在.NET中使用的任何东西），以最小化对类型化集合的影响

更新

---

今天我正在将一些.NET代码移植到Silverlight，这些代码大量使用了System.Diagnostics API，如TraceSource、SourceSwitch等，而Silverlight中不存在这些API。我在Silverlight项目中创建了这些的最小实现，并将它们放在Einstein.Diagnostics名称空间中。在这样做的过程中，我决定我需要一个约定来轻松识别模仿.NET框架的代码和我自己的代码。因此，我重命名了占位符文件，以使用@符号作为前缀。我还在这些文件中为类名加前缀。有趣的是，就C#编译器而言，@符号实际上并没有改变它们的类名。因此@SourceSwitch仍然编译为Einstein.Diagnostics.SourceSwitch，但在代码中我可以很容易地看到一些问题。我还用[SilverlightPlaceholder]属性修饰了这些类。

我使用protobuf net完成这项工作，并使用了以下几种方法：

• 在项目文件中使用条件编译符号来触发微妙的代码分支（是的，它并不完美，但可以工作）
• 重新介绍一些东西；这里的属性可能就是一个例子——您的代码仍然可以使用重新引入的属性，即使框架代码没有这样做；作为一个更极端的例子，对于compact framework，我不得不重新引入一个很好的

  表达式
  API，这很有趣

• 放下一些东西-p

---

然而如果您使用的是

ITypedList

（您提到的），我可以看到整个方法非常混乱；组件模型已经足够复杂了，不必强行通过黑客攻击。这完全取决于你在这条路上走了多远。也许4.0/

dynamic

会再次打开其中的一些选项？

解决问题的一个可能方法是从Mono项目中复制缺少的代码。当时，我用Compact Framework做了一个小项目，但它缺少整个System.XLM名称空间。我只是将Mono的全部内容复制到我的项目中，对其进行了编译，并且只做了极小的更改，效果非常好，iirc。

好的，很好，那么你就没有遇到任何我认为无法克服的问题了。很高兴听到你这么说，那么我一定会继续