SOA或WCF的反模式

虽然我可以找到很多提倡SOA或WCF的文章，但我的问题是什么不应该作为服务公开，我们从SOA失败中学到了什么。WCF是实现SOA的一种方式，如果我们使用WCF，这是否意味着我们正在实现SOA。当然，有很多人使用C语言编写无法维护的代码。

SOA作为一个概念是一个好主意

---

使用HTTP-WS/BPEL等实现的SOA是一个笑话，在我不那么谦虚的观点中，它值得一死。在了解到分布式事务的唯一概念是补偿事务后不久，我就不再认真对待这个系统了。。。下一个

我认为你是对的。在我当前的任务（web开发）中，对数据库的每一次访问都是作为服务实现的。正如首席架构师所说，我们是“纯SOA”。。。哇

事实上，这增加了一切的复杂性。当我想读取一个简单表的内容时，我必须生成8个项目、42个文件、8个程序集，可能还有9个配置文件

正如我所说的，这很复杂。有可能某处有人会忘记一个文件。。。将简单流程作为服务公开是愚蠢的

在我的书中，您应该在以下情况下将流程作为服务公开：

• 许多使用不同语言和框架的应用程序必须调用您的东西
• 涉及多个平台（Windows、Unix…）
• 正在处理的数据是企业的核心

另外，请注意，服务必须设计为服务，设计服务至少与设计库一样复杂：错误捕获必须精心设计，日志记录必须足够灵活，文档必须完整，等等

嗯，正如我所看到的，我每天使用的大多数服务都不会被其他人使用：没有文档，错误处理能力差，代码容易频繁更改，第二区域数据

---

非常有趣的问题。1点：o）

SOA是最糟糕的概念之一。SOA是一种体系结构风格，与web服务或任何技术无关。 我同意通过web服务和BPEL解释SOA显然是误导，BPEL通常与SOA无关，而是实现WS-orchestration的一种方法。小贩们把事情搞得一团糟

我推荐一本非常好的可下载书籍，它真正解释了SOA是什么：

那你就可以看书了

---

关于

我知道有两种主要的反模式：

• 通过服务层直接从业务层公开对象
• 公开特定的细粒度方法，如业务层中的方法

建议您的服务层包含粗粒度的通用方法，并允许它们接受和返回一些较大的基于消息的请求和响应。我们的目标是提供一个相当通用的接口，而不需要对如何使用服务进行太多的假设，也不需要大量调用来实现基本功能。尽量减少web服务调用的数量

以下是一些高层次的建议：

---

下面是guide所讨论的“message”类类型的一个具体示例，以及如何在WCF中实现它：

我发布了一些SOA反模式

---

关键是，很多人认为SOA将web服务前端置于逻辑之前，而忘记了产生的RPC（也称为）的含义。

从您描述的您实际上是在对数据库实现CRUD服务，这实际上是一个SOA反模式（请参阅CRUDy接口）-.我会小心地称之为反模式。我认为呈现RESTful业务对象很有价值。这种复杂性真的是由SOA引起的吗？这可能是由多层体系结构造成的，比如说，每层8层都需要一个单独的项目？服务层的任何完整示例应用程序，使用良好的模式，并在2013年更新（可能是VS 2012、WCF、.NET 4.5）？