应用程序完全SOA？

Question

完全基于SOA构建大型应用程序是否明智？或者只是一些部分？用户帐户登录，会计，gis映射，销售等？

换句话说，在HTML和HTML中为这样的应用程序构建GUI是否明智？通过ajax到后端的.NET Web服务进行所有交换的Javascript？

我看不到丢失所有.net .aspx功能，例如表单身份验证，查看状态等等。但是我的同事说如果我们要去SOA那就不需要.NET了前端。但我认为应该有某种平衡。你在哪里划线？是否所有对数据库的调用都要通过Web服务？

Answer 1

我只想说“有了SOA我们正在为变革而建设，而在传统系统工程方面，我们正在建立稳定性。”

稳定性的问题当然是，它只需要业务到目前为止 - 如果组织需要业务敏捷性，那么他们在实施SOA方面要好得多。

所以，这完全取决于你想要达到的目标，你就是应该划清界限的人。

我几天前在关于SOA的文章中读到它，因为我正在研究SOA。

---

修改

与此同时，我发现了this文章，并想与您分享。 该视频很好地解释了当前SOA的情况以及不同人的观点。

Answer 2

我想到了“如果我有一把锤子”这首歌的话。 SOA is an architectural approach将软件开发为一系列服务。在我看来，这对于具有低于即时延迟和有限带宽以及访问成本高的系统（这些都显然是高度主观的）是最好的。您不需要完整的SOA只是在组件之间松散耦合，我认为这是一个很好的目标。

数据库调用可以通过服务，例如采用ADO.NET数据服务，但是你必须权衡服务提供的内容。拿缓存。一种不错的SOA方法会考虑可能需要缓存数据以减少服务负载。那么您的数据可以在UI中陈旧吗？你允许这个用例吗？正确的登录信息是陈旧的（我知道一个粗略的例子，但可能可能需要解决的事情）。

总而言之 - 这取决于。我认为有些东西很适合SOA。如果采用DDD方法，则代表域的服务可能会这样做。通过这种方式，您的UI可以与域服务进行通信，而不是表中的行，因为数据库是在域服务后面抽象的。

请勿使用一种方法来解决所有问题。

另见SO question

Answer 3

这是一种面向服务的架构，而不是服务专属架构。

演示逻辑和管道必须住在某处;这一切都取决于它最适合居住的地方。

例如，假设您有一个UI组件，它依赖于对数据库的高度健谈但有效的调用，以生成对某些内容的复杂分析（请选择）。如果您的Web浏览器正在进行所有这些调用，则会引入大量网络延迟和并发问题。如果Web服务进行了所有这些调用，您可能会将表示逻辑放入其中以格式化该结果。

如果您正在使用会话状态（或Web服务期），那么您实际上仍在使用ASP.Net。尝试卸载它并查看您的Web服务是否仍在运行。

如果表示逻辑需要存在于服务器端，那么它最好能够存在于用于表示的框架内而不是Web服务IMO中。如果您还没有看过MVC 2，请执行此操作。它使得设置一个兼顾浏览器和服务器UI支持的应用程序变得非常容易（例如，由服务器端验证支持的jQuery验证器控件）。

相反，Web浏览器提供了一个富有表现力的平台。假设浏览器支持和团队知识，您描述的AJAX / SOA架构是一个很好的架构。我正在越来越多地使用它并试图使我的服务器页面更简洁，但我没有计划在任何时候从我的工具包中排除ASP.Net。

Answer 4

客户端实现应与SOA中的后端Web服务完全断开连接。该服务应该能够被任何客户使用。如果你在后端和前端使用.NET，因为它们可以被编码为直接通信，那么你就错过了这一点，因为现在它们是紧密耦合的，你现在拥有的是一个炉管应用程序。客户端应该不知道服务器端是如何实现的 - 如果使用.NET，Java或其他任何方式构建后端Web服务，则无关紧要。

在真正的SOA中，您应该能够在服务存储库中搜索服务，或者将输出与其他服务联系起来，或者使用XSLT创建在构建原始服务时不一定考虑的替代输出，以及在前端的任何客户端以标准方式使用它。

听起来你真正想问的是如何构建单个应用程序。 SOA的重点是通过可重用的接口提供标准数据集，这些接口没有特定的应用程序或实现。开始使用由SOA服务组成的整个后端构建单个应用程序将是一项艰巨的任务。在 MY 的思想中，应该构建每个后端服务，因为它的内在价值都在它自己的内部，并提供给整个SOA“域”。然后，当您或我决定创建一个执行X，Y和Z的客户端时，我们可以在SOA中找到这些功能并对其进行控制。