在Silverlight中使用.NET RIA服务有哪些陷阱？

Question

Silverlight可以使用WCF，Web服务，基于REST的服务，.NET RIA服务，但似乎最喜欢Silverlight和.NET RIA服务。

我想知道在使用.NET RIA Services实际实现SL时，是否存在任何常见问题[如果继续使用此组合可能会成为显示阻止者]。

谢谢， 拉胡

Answer 1

使用元数据（并自己编写）真的很痛苦。特别是当您需要更新模型时。 RIA教程应用程序在小型数据库上看起来非常好，但是使用由数十个实体组成的模型，您将花费更多时间来更新元数据，而不是编写应用程序本身。 这还与验证的定义以及来自资源的属性的所有验证和描述消息相关联。但是我们已经创建了一些T4模板，所以它们都会自动生成。

另一方面，我们在两个项目上使用RIA，我必须说这是我们能得到的最好的。我们在验证方面遇到了一些问题，但可以解决（在检查属性值是否已更改之前进行验证）。一旦您了解了RIA的内存管理（您不想将整个数据库加载到客户端的内存中等），它就可以在现实生活中使用。

不幸的是，没有银弹，所以如果您计划其他客户端而不是SL应用程序连接到服务器，您应该在其他地方观看（可能是WCP数据服务？）。或者，如果您不想更新客户端的数据，我认为RIA有点过分。

Answer 2

以下是我以前在RIA服务方面的不足之处： 另一方面，ria服务的缺点是缺乏灵活性。主要是它像管子一样连接服务器端的类和它的客户端代表，这样你在客户端类上操作，就像你直接在服务器端类上操作一样。如果他处理这个“管”的方式适合您的应用程序，那么您可以免费获得大量服务（无需编写任何代码......）。但是，有一些限制无法明确删除：

1）您在定义行为，属性等方面没有相同的自由来修改Web服务的行为方式。例如，您无法定义涉及多个Web服务的分布式事务。添加新端点很困难....你必须编写代码....而不是简单地修改配置文件。

2）您只能为每个类定义一个Insert / one update / one get方法。如果通过LINQ对客户端查询应用过滤，则仅应用于客户端，即所有数据都从服务器下载，然后在客户端上过滤。相反，如果您使用基于OData的WCF数据服务，并在客户端定义查询。此查询被转换为REST QUERY（在请求的URL中编码的查询）因此，您只需要从服务器下载您的过滤器所需的数据。有关WCF数据服务的更多信息，请参阅here。

3）与WCF数据服务相比，您没有像Ria服务那样提供验证服务。但是，您可以借助我的WPF验证工具包继续使用数据注释。 Silverlight，免费提供here

Answer 3

我一直在使用RIA-Services几个月和一些不同的应用程序，发现我可以让它做我需要的几乎所有东西。通过使用聪明的代码生成来处理大量的管道，它可以为您节省大量时间。

如果您使用EF创建直接CRUD应用程序，最好使用它，如果是这种情况，那么您应该没问题。

如果您正在做一些不同的事情，那么需要更多的工作，但它仍然（在我看来）是将数据提供给Silverlight客户端的最佳选择。我发现有一些小烦恼但没有显示停止者。

例如，我将它与SQL Credentials一起使用（用户使用他们的SQL登录登录Silverlight应用程序，并使用用户名+密码动态创建连接字符串）。这需要更多的工作，但它工作正常。

我还使用它从存储过程而不是实体向客户端返回数据，这又需要更多的工作，但它工作正常。

Answer 4

创建Ria服务只是为了与Silverlight一起使用。它们基本上是Silverlight准备使用的标准“软件包”。优点是你有很多服务而不需要编写代码，例如：

1. 支持数据注释
2. 支持会员提供商并登录
3. 支持转移到silverlight服务器端生成的异常。 Silverlight存在一个难点，即通过FaultContract使异常的正常错误传输变得困难。关键是浏览器无法处理所有错误代码。 Ria服务通过一个技巧来解决这个问题

Ria完成的所有工作都可以通过WCF和其他可用软件完成，特别是Wcf数据服务。例如，对于数据注释我发现this library比Ria服务做得更好，对成员资格的支持只需要激活WCF服务的现有成员资格端点，最后通过编写WCF行为可以轻松解决异常问题。代码可在此处获取：http：//www.silverlightshow.net/Storage/10Tips.zip关键是，通过Ria服务，您可以通过鼠标点击完成所有这些操作！另一方面，Ria Services真的很难定制......所以如果你不喜欢他们提供的标准解决方案，你根本就不能使用它们

Answer 5

Ria服务和休息服务提供了对服务器端类的非常类似的访问，这些类通常是实体框架类（但不是必须的.​​.....正如几个程序员似乎相信的那样）。 Ria Services的主要优点是它们通过在服务器端类上使用数据注释来处理验证并以智能方式执行：它们使用相同的数据注释自动生成客户端类，并通过自动实现INotifyDataError来验证它们。客户端类。如果使用自定义属性并放入.shared.cs（或.vb）扩展名，那么这些属性定义将复制到silverlight客户端并用于客户端验证，否则它们仅用于执行服务器端验证... ...有关更多信息，请参阅我的博客文章

here

Answer 6

我一直在使用SL4 + EF进行企业开发，我发现，如果你选择默认的开箱即用开发模式，很难用EF开发。我的意思是，你开发的任何一个屏幕，对于你使用表格/视图使用EF的数据，然后很快你的模型就会被污染。 现在添加20个新页面，其中包含6到10个表/视图后，在edmx中添加实体非常困难。我个人不喜欢污点。如果您看到我提出的一些问题，并且基于企业级开发的答案，请不要使用开箱即用的EF功能，使用POCO和PI创建域模型，然后使用它来开发应用程序。我还没有成功完成一个，所以我没有个人结果。 另外一件事，我注意到它本身与EF本身无关。花一些时间了解PRISM / MEF / Caliburn并使用它来创建您的应用程序。 SL中我不喜欢的一个问题是可测试性，即使SL单元测试存在，它本身也不是一个好的单元测试框架。同样测试EF也不是轻而易举。使用PRISM / MEF / Caliburn，不仅测试很简单，而且您的开发也将是真正的模块化。 因此，在开始开发之前，我的建议是查看其中一个框架，而不是使用EF outof框，使用POCO创建域模型，然后使用POCO在SL中使用它。 希望这会有所帮助。

Answer 7

我对MS真的很失望。从关于这个主题的讨论中可以明显看出，我并不是唯一一个有时会被MS提供的所有“工具”弄糊涂的人。问题是真的错过了MS的管理和协调。

结果是，有非常相似的产品具有相似的功能，其中一个做得更好，另一个做得更好。并且没有人能够分辨出哪一个更好用，甚至不会在下一个版本中支持哪一个。

我有两个例子。

1. 实体框架与.q 3.5中的Linq to SQL 这些非常相似，两者都是一样的。对于较小的项目，L2S意味着更好，对于企业的项目，EF更好。 L2S拥有更好的设计器和更好的LINQ实现。 EF应该能够将更多的数据库表映射到一个实体，但这从未真正发挥作用。而且，顺便说一下，甚至EF4也没有一个非常有用的L2S功能，即AssociateWith<>功能。突然间，L2S不再受支持，每个人都应该使用EF。应该有人在一开始就说“停止，我们有两种类似的技术。让两个团队在一起，制作两种产品中最好的产品。”

2. RIA服务与WCF数据服务 同样，同样的问题。两个不同的团队致力于两个类似的产品。两者都有一些更好的功能。但肯定的是，可能有一种产品具有两种功能。

我们应该如何决定使用哪一个（除了花费大量时间来掌握两者）？哪一个将被弃用？

...这可能是一篇博文，而不是回答这里。对不起，我只需要把它写在某处，因为有很多关于这些问题的讨论，它似乎是一个合适的地方。我一定会尝试稍后发表博客。

Answer 8

我在我的博客中写了一篇关于Ria WCF数据服务和WCF休息服务的文章，其中还使用了here中得出的一些结论。