跨平台应用程序WPF，ASP.NET，Silverlight，WP7，XAML

Question

考虑到所有应用程序都将与Web项目（将使用云或Web服务）进行交互的事实。 有没有办法在应用程序之间共享我的类模型？

如果是，最好的方法是什么？

关于从Webservice发送/接收数据，序列化和反序列化，如何在不必手动填充对象的情况下以简单的方式执行此操作？

有关此应用程序的任何信息都非常有用！

Answer 1

一般情况下，在这样的应用程序之间共享域模型并不是一个好主意，因为您在它们之间创建了硬依赖关系，即对域模型的任何更改都会影响所有应用程序，迫使您同步Web版本，电话 - 和桌面应用程序。

我建议根据每种应用类型的特定信息需求创建单独的模型，这会增加当然的复杂性，但根据我的经验，与其他方案相比，这是可管理的。

不确定您的序列化问题，如果您使用WCF调用服务这是非问题，则会为您处理。

为了填充您的域类，我建议使用AutoMapper，我在几个项目中成功使用了它。它可以根据名称自动从一个类映射到另一个类，您只需指定例外（即字段名称不映射或您需要某种类型的转换逻辑）Automapper on github

Answer 2

通过简单地引用它，您可以在WPF和ASP.net之间共享Common.Domain.dll以及所有类型。

然后，您可以在WCF客户端和服务器上共享相同的类型（请参阅在线示例，例如http://blog.walteralmeida.com/2010/08/wcf-tips-and-tricks-share-types-between-server-and-client.html），以允许单独的应用程序域进行通信。

最难的是在Silverlight中共享它们，因为AFAIK silverlight使用一个简化的.net框架和它自己的编译器。一个技巧是将文件快捷方式添加到Common.Domain.dll中定义的c＃类或使用可移植类库（http://msdn.microsoft.com/en-us/library/gg597391.aspx）

然而，所有这些共享是一个好主意是一个单独的问题，它高度依赖于您的发布策略。

Answer 3

要在应用程序之间共享域模型，请查看Microsoft的Portable Class Libraries Visual Studio扩展。它包含用于创建可在WPF，Silverlight和Windows Phone中的一个或多个上运行的库的模板。生成的编译.dll可以在所有三个平台上使用。

我已经使用这个项目类型在WCF服务和Silverlight消费者之间共享公共DTO，等等。

要在您的域名模型和DTO之间进行翻译，请查看AutoMapper。

Answer 4

有人建议不要将服务器端域模型分发到客户端应用程序，而是通过Web服务代理生成器生成客户端实体并使用AutoMap进行映射，但我更倾向于坚持通过以下方式与客户端共享实体的方法。共享DLL。这有各种各样的优点：

赞成

• 没有双重编码。
• 没有将代理对象映射到真实对象。因此没有性能损失。
• 在服务器上然后在客户端实体上没有双重验证实现。
• 共享引用实体对象的实用程序库。您不必再为客户端代理生成的实体编写实用程序库，这是大的痛苦。
• 设计一次，无处不在。

缺点

• 实体库必须是普通的类。没有引用外部库。
• 无法删除或重命名现有属性。

现在我理解有一些关于服务器实体被改变并破坏客户端代码的反对意见。但在现实生活中，您拥有客户端和服务器，您始终可以将新版本发送到客户端。即使您不这样做，您也可以随时对实体进行版本更新，并引入新服务以发送新版本的实体。破坏兼容性的可能性也很低。它只会在您删除属性或更改现有实体上的属性名称时中断。这通常是低概率。根据我的经验，它主要是为实体添加新属性。即使您向实体添加新属性，具有旧实体DLL的旧客户端仍然可以工作。它可以对SOAP负载进行反序列化。

所以，尽管有一些缺点，但在我看来，优点超过了缺点。所以，我总是有一个实体DLL，它包含我的所有实体作为POCO并与客户端应用程序和服务器共享。

希望这有帮助。

Answer 5

我知道有几个选择。

1. 在您的网络服务中定义模型，当您的应用程序添加对服务的引用时，您还将获得模型定义。

2. 使用文件链接并将您的域文件链接到每个项目（我们目前使用一些魔术来完成客户端和完整.net之间的差异（使用自动播放器或反射来填充本地对象）

3. 您是否在每个

引用的单独项目中使用了域模型

Answer 6

我建议有一个非常精简的域项目，该项目可以完成大部分工作，但仍为项目类型（WPF，ASP.Net等）提供公共层。

由于域旨在用于所有不同类型的项目，因此它不能包含所有必需项目类型中不可用的命名空间，这将很困难。

要解决这个问题，我建议您创建一个服务项目，该项目将通过编译器指令或服务提供域项目的扩展功能是每种类型项目具有不同项目的命名空间。 （这种方式当发货只说Silverlight时，您将发送 Services.Silverlight 以及域和您的Silverlight项目。）这将减少编译器指令的数量。

完成上述项目后，您可以开始为所有其他项目创建前端和特定于应用程序的逻辑。然后，您可以使用自动映射器或其他工具将您的（可能）视图模型映射到域中的模型。

将域和服务作为所有核心逻辑的一层将在以后帮助您扩展到其他项目类型。