5

刚刚经历了一个小型试验会议，试图了解将我们的 .NET 类库或至少部分类库引入 Silverlight 需要多少工作，以便我们可以在两个世界之间重用业务逻辑，我想知道其他人是否有这种事情的经验。

我注意到的事情，从我的头顶上消失：

  • 缺少很多属性（例如，可浏览（假））
  • 许多接口缺失或存在，但为空（ICloneable 被隐藏，ITypedList 缺失）
  • 反射差异（所有可达的都需要公开）
  • 一些基类差异（没有组件？）

所以我想知道，我是否真的可以将其视为一种可能性？

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

我创建的实际业务测试类与我为 .NET 所做的 99.5% 相同，只有一些小的更改也可以在 .NET 中轻松使用，只是不像我在查看之前所做的那样银光。换句话说，共享业务逻辑看起来是可行的，前提是我可以使基类兼容。

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

那么有人有这方面的经验吗？任何提示或指南？

值得吗？它当然值得更多研究。

4

4 回答 4

4

这绝对是可行的。

这是在这里的一个项目上完成的；Silverlight 项目包括 C# 项目，并且有一些#IF语句处理一些事情（如 log4net 声明），而其他时候事情只是重新实现。但总的来说，这是一个巨大的胜利，你绝对应该尝试它（当然，我们已经成功了）。

- 编辑：

但有一点是，我们的 OR/M (LLBLGen) 没有内置支持通过 Silverlight 向下发送的“简单”对象。但是有人写了一个插件来处理它，这很有帮助。因此，可能值得考虑您使用的是哪种 DAL，以及它对 Silverlight 的支持程度。

于 2010-01-10T21:57:34.157 回答
4

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

  1. 经常使用分部类和 #if !SILVERLIGHT 将代码分成 Silverlight 可以处理的部分。
  2. 尽可能使用代码生成。例如，我一直在尝试生成 Silverlight 等效属性的 T4 模板（例如 DisplayAttribute 而不是 DescriptionAttribute）
  3. 每当有 Silverlight 未实现的接口/属性（例如 IDeserializationCallback、ICloneable、INotifyPropertyChanging）时，我将在 Silverlight 应用程序中创建一个同名的虚拟接口，只要我知道实现不会被使用不是问题。
  4. 最后，值得注意的是，在Silverlight 4中，只要没有 Silverlight 不支持的依赖项，程序集格式就允许在 Silverlight 和 .NET 之间共享二进制文件。

关于单独的基类的另一个注意事项 - 创建一个派生自 Silverlight 和 BindingList（或您在 .NET 中使用的任何东西）中的 ObservableCollection 的抽象类可能是值得的，以尽量减少对类型化集合的影响。

更新 今天，我正在将一些 .NET 代码移植到 Silverlight 中，这些代码大量使用了 System.Diagnostics API，如 Silverlight 中不存在的 TraceSource、SourceSwitch 等。我在 Silverlight 项目中创建了非常小的实现，并将它们放在 Einstein.Diagnostics 命名空间中。在这样做时，我决定需要一个约定来轻松识别模仿 .NET Framework 的代码与我自己的代码。所以我重命名了占位符文件，并在它们前面加上 @ 符号。我还在这些文件中为类名添加了前缀。这样做的好处是，就 C# 编译器而言，@ 符号实际上并没有改变它们的类名。所以@SourceSwitch 仍然编译为 Einstein.Diagnostics.SourceSwitch 但在代码中我可以很容易地看到有些事情发生了。一世'

于 2010-01-10T22:10:57.123 回答
2

我使用 protobuf-net 执行此操作，并使用了几种方法：

  • 项目文件中的条件编译符号以触发微妙的代码分支（是的，它并不完美，但它有效）
  • 重新引入一些东西；属性可能是这里的一个例子——你的代码仍然可以使用重新引入的属性，即使框架代码没有；作为一个更极端的例子，对于紧凑的框架，我不得不重新引入大量的ExpressionAPI，这很有趣
  • 只是放下一些东西;-p

但是，如果您正在使用ITypedList（您提到的），我可以看到整个方法非常混乱地分崩离析；component-model 已经足够复杂了，也不必强行破解。这真的取决于你在这条路上走了多远。也许 4.0 /dynamic会再次打开其中一些选项？

于 2010-01-10T22:34:49.667 回答
2

解决您的问题的一种可能方法是从 Mono 项目中复制缺失的代码。过去，我使用 Compact Framework 做了一个小项目，但它缺少整个 System.XLM 命名空间。我只是将整个东西从 Mono 复制到我的项目中，编译它，它只需很少的改动就能很好地工作，iirc。

于 2010-01-10T22:38:11.080 回答