我有一个网站(ASP.NET)和一些Winforms(.Net 2.0)，用于一个项目(用C＃编写)。我将Web服务(IIS6)用于既需要在企业内部发送电子邮件的任务。

我认为Web服务很好，但是根据经验，我想在Web服务中应该做什么和不应该做什么？

解决方案

听起来服务导向架构有限(至少，我认为这就是我们所要达到的目标)，根据Gartner的说法，这意味着我们很快就会有钱。 :)

我发现SOA给我带来的好处实际上归结为所涉及系统的异质性(像我们这样的声音在那儿不合格，因为它全都是.NET)，而SOA的缺点主要是因为XML的冗长性质。是的，SOA不需要XML，但这是当前的大多数，恕我直言。

但是，如果我们不担心带宽/解析罚款，谁在乎呢？也许我们不是每分钟通过10,000个服务呼叫。通过这种实现方式，我们仅使用WS而不是子程序来遵循DRY，并且我们坚持的是一种本质上与多个系统兼容的标准。

有更糟糕的方法。

在我看来：

Web服务应保留用于以下代码：

• 我们或者不能分发，或者不想分发。或者，
• 需要认真扩展的代码。

一个示例是多个应用程序需要访问的定制业务逻辑。

我们不想放入Web服务的代码包括：

• 基于性能的代码；
• 仅适用于相关应用程序的代码。

Web服务/ SOA的新趋势似乎是或者多或者少公开宿主应用程序可以使用的轻量级中间层。面向SOA的应用程序没有通过服务公开单个方法调用(如示例)，而是具有广泛的数据/操作合同，这些合同充当"传统"中间层程序集。

尽可能少，但仍然有用。

默认情况下，不要将返回对象的每个字段都放在返回数据中，也不要公开现有类的每个方法。

也读这个...