2010-08-31 69 views
4

首先,如果这个问题以前曾被问过,但是我找不到直接回答这个问题的道歉。WCF服务契约设计。用例控制器是否合适?

这是我的问题。我已经继承了一个产品,它被设计得非常灵活,以至于在(silverlight)表单上填充几乎每个组合框和文本块都需要一个服务请求。某些屏幕只需要15个独立的请求就可以填充!

现在我已经多次与WCF Web服务合作过,并且将服务合约拆分成小的离散操作从来没有太多过关,..可悲的是,这个项目并非如此。所以它让我想知道...

还有没有计划在我们自己的围墙之外暴露服务。有没有计划为此特定服务编写另一个客户端。所以我不能在服务端写一个'用例控制器'吗?所以,在 '创建投诉' 屏幕,而不是像请求列表...

  1. GetComplaintTypes
  2. GetCustomerTypes
  3. GetAreaDetails
  4. 等等...

填充表单我只需要一个名为'GetCreateComplaintData'的单一操作合同。当只有一个客户端需要将所有这些请求聚合并同步化为有意义的东西时,如此众多的操作暴露在这样​​的粒度中似乎很疯狂。为什么不公开一些有意义的东西呢?

更重要的是,如果您不打算将服务API暴露给第三方,那么这是否比在数据库中暴露CRUD操作符更好?

感谢所有帮助和意见。 在此先感谢。

回答

2

我认为你的想法很好。

作为一种介于两者之间的方式,您也可以考虑将多个WCF请求批量合并为一个的方法。这种方法以及如何对其进行编程描述如下over here

+0

:-)。我正在通过一大堆代码做这件事。这就像跑在泥里! – Stimul8d 2010-08-31 12:22:51

+0

标记为有用的链接正确。 – Stimul8d 2010-08-31 13:54:50

+0

你应该看看http://code.google.com/p/agatha-rrsl这是一个基于Davy Brion的原创想法开发的开源项目。 – 2010-09-01 00:47:49

1

我想你首先必须确定性能问题的确切位置。 IIS无法处理您发送给它的请求数量的确是真的吗?或者每个请求都花费太长的时间,因为数据库无法提供数据,并且它看起来像IIS无法承受因此造成的压力。

我不相信有以下情形的两者之间的真正区别:

  • ,每执行一个数据库select语句小的请求。
  • 一个执行大量数据库选择语句的大型请求。

当然,我不确定你的具体情况,但在性能方面,事先知道你为什么要优化是明智的。

+1

连接数量有所不同。 – 2010-08-31 12:33:16

+0

我看到的差异是我发送/接收的报头数据与实际有效负载差不多。另外,在Silverlight客户端中同步这些调用也是一件非常痛苦的事情。 – Stimul8d 2010-08-31 12:35:49

+1

所有的头部开销可能是一个问题,我明白这一点。而Silverlight应用程序的异步特性并不会让它变得更容易,我曾经遇到过这种情况。我想说的是,你应该事先确定你正在解决正确的问题。祝你好运与应用程序。 – 2010-08-31 17:05:18

1

业务逻辑顶端的WCF服务应该暴露高级业务操作的正面而不是低级别的CRUD操作。 CRUD操作服务用于公开数据(如WCF数据服务)。

+0

Web服务做什么但暴露数据?我同意这是一个坏主意,但从概念上说,那里没有真正的区别吗?我的意思是,对于大多数位于CRUD操作系统之上的应用程序,那里有什么业务逻辑? – Stimul8d 2010-08-31 12:41:21

+1

分布式接口不应该健谈。在最好的情况下,这意味着分布式系统的客户端应该能够使用单个Web服务调用来执行单一操作以减少往返行程。在你的情况下,行动是“准备表格”。由WCF公开的服务外观应收集来自CRUD操作的所有数据,并将其发送回单一响应。 – 2010-08-31 12:55:12

+0

同意所有观点。我只是说...对于很多'数据'应用程序的形式,这两者之间没有太大的区别。 – Stimul8d 2010-08-31 13:19:48

0

用于使用与WCF一个CRUD图案曝光从DB数据的最简单的方法是使用WCF数据服务。实际上,您不会在服务器端开发任何比想要公开的模型更多的东西,如果您使用它来访问数据库,也可以从EF模型自动推断出它。

Pablo。